XLS-69: Secure Transaction Simulation through the “simulate” API Method on XRPL
Author: XRPL Korea & Park DoYeon (@p6rkdoye0n)
The following text is provided for informational purposes only and does not constitute investment, legal, or advisory responsibility in any form. It is not intended to recommend investment in any specific asset, and decisions should not be made based solely on the contents of this document.
Abstract
In blockchain technology, once a block is confirmed, it cannot be rolled back. The same applies to the XRPL (XRP Ledger). Once a ledger is validated, it cannot be reversed. If a transaction performs unexpected actions, it can cause significant damage. However, the traditional RPC (Remote Procedure Call) using the submit API method directly submits transactions to the mainnet, which may not effectively address potential unexpected damages.
Therefore, in this article, we will discuss “XLS-69d: Simulating Transaction Execution,” a proposal by XRPL aimed at preventing unexpected damage caused by unforeseen transaction behaviors through testing transactions with the simulate API, which differs from the traditional submit API.
Table of Contents
Introduction
- The Need for Transaction Simulation in XRPL
Main Content
- How the simulate API Method Works and Its Differences from the Traditional submit Method
- Security and Performance Issues: Risks of Malicious Nodes and Various Security Vulnerabilities
Conclusion
- Expected Benefits and Future Development Directions
Introduction: The Need for Transaction Simulation in XRPL
The XRPL protocol supports a variety of transaction types, and more types are added over time. Many transactions are complex and can have numerous modes, flags, and parameters.
Especially, some of these combinations can lead to unpredictable results. Transactions often behave differently depending on the current state of the ledger. This makes it crucial to understand the expected outcome of a transaction and verify that its effects align with expectations, particularly for high-value transactions.
For example, when trading XRP, security vulnerabilities such as integer underflow and integer overflow can occur if an attempt is made to store data beyond the binary bit limit, leading to unintended consequences.
Transactions often behave differently depending on the current state of the ledger. If the above security vulnerabilities were to occur in a transaction processed on the mainnet, it could lead to significant security threats. This makes it particularly important for high-value transactions to understand the expected outcome and verify that its effects align with expectations.
To address this, Ethereum offers frameworks like Foundry and Hardhat, which provide the ability to fork the state of the mainnet and simulate transactions before executing them on the mainnet.
In Foundry, the script and test commands can execute functions similar to the simulate API of XRPL. The image above shows a log generated using the test command, illustrating whether the intended transaction flow is maintained by the developer.
The first line is the command line used to run the test command to simulate the developer’s code. The logs below show an “OK” sign when the transaction is processed correctly.
If the transaction is not processed correctly, the log provides detailed transaction flow along with the data sent, indicating which part of the code failed. Once a successful simulation result is achieved, the developer can add the “broadcast” option to submit the transaction to the mainnet. This allows developers to verify that the results match their expectations before submitting transactions to the mainnet, thus preventing damage from unexpected outcomes.
“XLS-69d: Simulating Transaction Execution” follows the same principle. This proposal uses the simulate API method to test transactions without committing them to the XRPL network, preventing potential damage from unexpected results.
Main Content: How the simulate API Method Works and Its Differences from the Traditional submit Method
The simulate API method communicates using specified request and response fields. The request fields, response fields, and working principles of the API are as follows:
simulate API Method Request Fields
- tx_blob: A string field used when the transaction to be simulated is in binary format.
- tx_json: An object field used when the simulated transaction is in JSON format.
- binary: A boolean field; if true, the transaction data and metadata are returned in a string serialized tx_blob format. If false, they are returned in a JSON format as tx_json. The default value is false.
Clients can send requests to the simulate API method in the following ways:
By specifying the command as simulate, the simulate API method is called, and a payment request is sent in JSON format according to the tx_json request field.
simulate API Method Response Fields
tx_json: This field is included in the response when binary is false. It is an object field and returns the simulated transaction, including automatically populated values.tx_blob: This field is included in the response when binary is true. It is a string field and returns the simulated and serialized transaction, including automatically populated values.ledger_hash: This field is always included in the response. It is a string type data that provides the unique identifying hash of the transaction.ledger_index: This field is always included in the response. It is a number type data that indicates the index of the ledger containing the transaction.meta: This field can be an object or string and contains metadata that describes the result of the transaction. If the transaction fails, it includes a code (e.g., non-TEC code) indicating that it is not included in the ledger.
When a request is made to the simulate API method as described above, the following response is returned:
You can always see the Ledger_index and Ledger_hash included in the response. Additionally, due to the request field sent in tx_json format, the response field is also in tx_json format. Finally, we can observe that the payment request transaction was successful, returning a significant amount of metadata.
When analyzing the differences between the traditional submit API and the simulate API at the code level, the only difference lies in the command.
Additionally, the traditional submit API method submits transactions to the XRPL network, but the simulate API method allows for testing transactions and viewing results (including metadata) without committing to the XRP Ledger.
The simulate API, using JSON data, enables the development of simulation tools for testing cases within development frameworks or various products. Although the language is not restricted, Python can be used to send requests in JSON format to the RPC URL. Here is an example of such a code format:
The simulate API method provides an efficient way to safely experiment with transactions on all ledgers, including the mainnet ledger. For testing purposes, users can apply transactions to the mainnet (or other) ledgers without actually submitting them permanently. This allows developers and users to confidently test and improve transactions before committing them.
Main Content: Security and Performance Issues: Risks of Malicious Nodes and Various Security Vulnerabilities
The potential security threats when using the simulate API method are as follows:
- Human Risks: While the simulate API method does not actually submit transactions, if a user mistakenly processes the test transaction using the submit API method, the transaction will be submitted to the mainnet. This can expose the system to potential security threats from test transactions. Users must be careful to use the correct RPC when deciding whether to submit or not.
- Malicious Rippled Node: Since simulated transactions should not be signed, a malicious Ripple node should not be able to submit transactions that the user only intended to simulate. However, a malicious Ripple node could still lie about the execution of the user’s test transactions or preemptively execute the transactions.
- Possibility of a DoS Attack: If complex transactions affecting many ledger entities are involved, a malicious user could perform a DoS attack on a Ripple node by excessively calling this function. To prevent this, performance testing should be conducted, and if the load on the node is too high, the function should be implemented as an admin-only method.
Conclusion: Expected Benefits and Future Development Directions
The “XLS-69d: Simulating Transaction Execution” proposal effectively addresses the damage caused by the blockchain’s characteristic difficulty in rolling back a confirmed ledger. Additionally, it aims to prevent potential damage from unexpected transaction outcomes by allowing transactions to be tested beforehand. Since testing is conducted without committing to the mainnet, various functions of XRP can be experimented with at no cost. Furthermore, it provides debugging capabilities when results differ from expectations, which is expected to lead to the development of various products and applications on the XRPL in the future.
This is anticipated to significantly contribute to the activation of the XRPL developer ecosystem. Anyone can test various use cases on their products, and developers can share their test cases in open-source remote repositories like GitHub, gaining a certain level of trust from users.
One concern is that such a proposal might lead to an increase in hacking incidents. Hackers could test various use cases like developers without paying transaction fees. If they discover the results of abnormal malicious transactions, they could immediately submit them to the mainnet using the submit API method and attempt to hack. I believe that the convenience for developers and security incidents are always in a proportional relationship, and I am worried about the increase in intentional hacking incidents.
However, the simulate API itself is not the cause of hacking incidents. Hackers attempt to hack by clearly analyzing the Root Cause of the problem. While the simulate API provides convenience, it is not the fundamental cause of hacking. To overcome this, developers should continuously conduct security audits and bug bounties to eliminate the Root Causes that could be exploited by vulnerabilities.
If these hacking threats are adequately considered, like Foundry and Hardhat in Ethereum, the simulate API could establish itself as a representative framework for XRP. It could showcase more products, leverage the low fees and fast transaction speeds of XRPL, and positively impact the blockchain ecosystem.
✍ Medium: Park DoYeon | 🕊️ Twitter: p6rkdoye0n | 📧Mail: parkttule0305
