0069 XLS-69d: Simulating Transaction Execution

[mvadari]

An updated version of this spec can be found here: XLS-69: Simulate.

The earlier version can be found by looking at the edit history.

[tequdev]

It might be better to clearly note that there is no guarantee that the results of simulate api will be identical to the actual results of submit api.

[JosepMariaVila]

And maybe statements like "allows users to "apply" transactions to a Mainnet (or other) ledger without actually submitting the transaction"could be avoided... It's like all the time the text tries to avoid saying "apply transactions to the Mainet" but ends up saying it.

[mvadari]

Added an FAQ addressing that 🙂

[Bronek]

I am slightly worried about the cost of processing such transactions in validators. We know there are certain transactions which can be expensive to process e.g. in terms of CPU time, and it would be pretty bad if validators started processing these in large numbers, without actual change in the ledger, but with all the associated data processing cost.

To address this concern, I would suggest to add an error code tecSIMULATION_UNSUPPORTED and a configuration value, defaulting to false for validators, to the effect "simulation is supported"

[Bronek]

Thanks; it seems we agree, I just want to point out that this will require a specific error value (so the users are not confused as to why their simulated transactions fail)

[mvadari]

It will not require a specific error code. You can error at the RPC level instead of at the TER level if you don't want to support this particular RPC.

[Bronek]

Good point 👍 I did not think of this. Although I am not convinced that failing at the RPC level be better, need to think it through.

[mvadari]

That's how it works for other RPCs, and how it would work if you're e.g. missing a required field in a transaction. IMO it's an RPC-level error because it's an RPC-related error, not a transaction processing error.

[intelliot]

Just to clarify: validators should not allow public API access. (And they generally do not.) simulate is in the same category as other CPU-intensive public methods like account_tx, gateway_balances, etc.

In rippled.cfg under [server], validators are not configured to provide API access to the public.

[jscottbranson]

This functionality seems useful, however, I wanted to clarify the underlying purpose. Do you see this as predictive of the outcome of large or complex transactions (i.e., the volume of currency that is delivered), or is this targeted toward ensuring the transaction is formatted and submitted correctly?

Given how dependent transaction outcomes are on the Ledger's state, it seems the former would not be possible, as the state could change substantially in the interval between the simulated and real transactions (even if the real tx hits in the subsequent ledger to the simulation).

If the latter, I'm curious how the simulated transaction benefits from being tested on the main network. I admit it is more convenient not to switch networks, but it's realistically not a massive barrier. Perhaps access to more paths and liquidity could give a more accurate simulation?

Finally, is there reason to believe a simulated transaction could take more resources than the actual transaction? It seems like the actual would always take more, since the signature needs to be verified, so I'm interested in the line where this would become admin only.

[mvadari]

Do you see this as predictive of the outcome of large or complex transactions (i.e., the volume of currency that is delivered), or is this targeted toward ensuring the transaction is formatted and submitted correctly?

I would say a bit of both.

Given how dependent transaction outcomes are on the Ledger's state, it seems the former would not be possible, as the state could change substantially in the interval between the simulated and real transactions (even if the real tx hits in the subsequent ledger to the simulation).

That could be an effect, yes. @tequdev suggested adding a caveat that you're not guaranteed to get the results you get from simulate when you actually submit the transaction for that reason. I wouldn't go so far as to say that it's "not possible", though, as you can still gain a lot of value from getting the spot result even if it would change later (just as you derive value from knowing the spot price of a trading pair even if your offer isn't processed for a couple of ledgers after that).

If the latter, I'm curious how the simulated transaction benefits from being tested on the main network. I admit it is more convenient not to switch networks, but it's realistically not a massive barrier. Perhaps access to more paths and liquidity could give a more accurate simulation?

If you're trying to run a complex transaction, or just a DEX transaction, it's rather difficult to replicate the entire system in a testnet. There may also be factors and edgecases that your transaction will run into that you simply don't think about replicating in your testnet recreation. Plus, there is much less activity on testnet compared to mainnet. So it would be much easier to just dry-run your transaction on mainnet instead.

Finally, is there reason to believe a simulated transaction could take more resources than the actual transaction? It seems like the actual would always take more, since the signature needs to be verified, so I'm interested in the line where this would become admin only.

This RPC isn't guaranteed to be admin-only right now. That decision will be made based on performance testing; if it's decided that it's too resource-intensive to be a public method, then it will be admin-only (or, like the signing RPCs, be up to the node operator to enable). Nodes don't have to deal with that much transaction processing normally, since the network is usually doing less than 30 TPS. With simulate that number could rocket up in terms of local resource usage.

[Tapanito]

I love it, it's an excellent feature!

Though, I do have one concern. While a malicious node cannot submit these transactions, they can replay them. For instance, imagine someone is testing a valuable DEX trade. A malicious node will gain information that a trader might submit this transaction in the future or verify that executing this trade is profitable. Before the user submits the real transaction, the malicious node might submit the same transaction using their own private account.

That is to say; I think it's important to also caveat this API endpoint that it should only be called on trusted nodes or, even better, on one's own node.

[Bronek]

Oh that made me aware of another gotcha - replay attack. If the node receiving the request is malicious, and tx_json is fully formed with signature, it could be passed to submit by the malicious node. Ideally we want the signature of tx_json to simulate to be different than one to submit, e.g. as-if there was some difference inside the transaction itself.

[mvadari]

That is to say; I think it's important to also caveat this API endpoint that it should only be called on trusted nodes or, even better, on one's own node.

Yes, malicious nodes are discussed in the Security section but that specific concern isn't called out.

Oh that made me aware of another gotcha - replay attack. If the node receiving the request is malicious, and tx_json is fully formed with signature, it could be passed to submit by the malicious node. Ideally we want the signature of tx_json to simulate to be different than one to submit, e.g. as-if there was some difference inside the transaction itself.

The signature must not be included in simulate, for that exact reason.

[Bronek]

The signature must not be included in simulate, for that exact reason.

Great, thanks - I missed this part. I suggest the error in this case should be the same as if the signature was invalid, i.e. temBAD_SIGNATURE

[mvadari]

The signature must not be included in simulate, for that exact reason.

Great, thanks - I missed this part. I suggest the error in this case should be the same as if the signature was invalid, i.e. temBAD_SIGNATURE

In that case, the error will be an RPC-level error. I'd prefer if the transaction processing part of rippled isn't entered at all if there is a signature included in the transaction.

[Tapanito]

So with this attack, I wouldn't be submitting your transaction, but mine. It would just do exactly the same thing as yours. The absence of the signature doesn't help against this

…

On Tue, Jun 4, 2024, 17:20 Mayukha Vadari ***@***.***> wrote: The signature *must not* be included in simulate, for that exact reason. Great, thanks - I missed this part. I suggest the error in this case should be the same as if the signature was invalid, i.e. temBAD_SIGNATURE In that case, the error will be an RPC-level error. I'd prefer if the transaction processing part of rippled isn't entered *at all* if there is a signature included in the transaction. — Reply to this email directly, view it on GitHub <#199 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMDKUYLJ5A2WSDOC3MYAUDZFXSOBAVCNFSM6AAAAABIXCEIZSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TMNRXGEYTK> . You are receiving this because you commented.Message ID: ***@***.***>

[mvadari]

Yes, I was responding to Bronek's concern in that comment. You always need to be aware of the possibility of a malicious node when submitting requests to the network, since they could be manipulating your data. I agree that them frontrunning you is also a concern, and will add it to the security section.

[mvadari]

Added a bit to the security section to address that concern 🙂

[mvadari]

Per the new XLS Contributing process, it is my opinion that we have reached a "well-refined standard."

As such, I propose that we move this discussion to a file (via #207) and work on final changes using additional PRs, for better change-tracking.

Please comment here if you would like to object to moving this spec/discussion forward in the process into a DRAFT spec.

(Note that per the Contributing guidelines, moving a spec into the DRAFT state does not mean any kind of endorsement, nor does it mean that this specification will become adopted. It is solely meant as a mechanism to enable better change tracking using PRs.)

[interc0der]

As someone that does not stay up-to-date with standard discussions anymore, this seems like a good one. Glad to see it is moving forward with some urgency.

[mvadari]

Closing this discussion since the spec has been initially merged via #207.

For further discussion or changes, please open a PR on XLS-69d.