RPC Request: Enable simulation of all Stellar operations

[dark wing]

Hello!

Wanted to start a quick discussion thread about enabling the RPC to simulate all Stellar operations.

A potential use case for this would be simulating path payment operations. It appears like the resultXDR should return information about the trade, including the simulated amount received at the end of the path payment. Bots would be able to simulate via local RPC against both Stellar Classic DEX / LPs and Soroban LPs if attempting to perform arbitrage without the need for running a local Horizon instance (which is a massive resource cost).

Thoughts? Mostly curious if there was a technical reason this was prohibited.

[elder hamlet]

@dark wing I like this idea, though I'm not sure how feasible it is to develop something like this since simulation relies completely on the soroban VM itself to calculate the results of the simulation. Enabling simulation for all operations would mean having to replicate this logic in rust/import from c code which I'm not sure how feasible this is.

For what is worth though, specifically for things like this we have started building in Zephyr ⁠#1222301534440657068 message which would allow to find the best routes/write logic yourself. No need to run infra here too!

[sage vigil]

I think with the current architecture that would require using some special mode of core execution that emits meta but then rolls back all the changes. I don't think it's feasible to reimplement the core logic in rust just for simulation (also, there is no footprint or resources involved, so the only thing that you could get from preflight is really the metadata with ledger diffs)

that said, maybe eventually core logic would move into rust. but that's not even in plans at the moment.

[dark wing]

I think specifically for the use cases I have in mind there is a massive advantage in being able to do this all locally. I will take a look tho!

[elder hamlet]

could still be done locally fwiw, you'd just have to load the entries from the rpc/mercury, or your local core

and run the VM locally

[dark wing]

Yeah, some form of "execute, roll back, and return the tx.result_xdr" would be perfect. I'm not even sure the result_meta_xdr stuff would be necessary.

I thought there might have been some opportunity to re-use the soroban-rpc's implementation of simulation, given invokeHostOp is technically a Stellar operation, but it sounds like that isn't the case.

Since this will likely be a bit more work, what would be the best way to track this request? Github issue against RPC?

[elder hamlet]

not sure though what are the advantages of doing this locally, what did you have in mind?

[sage vigil]

I don't think RPC can help much here, at least not before there is respective core-side support. so maybe you could make a feature request for stellar-core

[elder hamlet]

the "issue" is that the rpc is not applying the transactions, it's only executing the soroban VM with the params from your stellar operation

so it's not reusable for other ops as well

but it would surely be cool to have at some point a library which applies transactions and emit meta without having to actually run core.

[sage vigil]

(if the approach with using a core instance would work for you, that is)

[elder hamlet]

can't the logic of ops application be grouped in a library? this seems more usable and more rpc alike.

[sage vigil]

sure, if you have a spare few months 🙂

we don't have that, unfortunately

[dark wing]

Using core seems totally fine. It's easy enough to get running, and one is already running if you run the RPC locally.

[sage vigil]

yeah, if core supported that, then RPC could just have an endpoint that forwards requests to core. I'm not sure how hard would that be; on the surface it seems like this should be reasonably easy to do. but likely there are some non-trivial issues to solve there

[dark wing]

arbitrage and liquidation bots and the only real use case I have in mind. These are often very time dependent, resource heavy, and easily frontrun, so there is an advantage to running your own infra.

[elder hamlet]

yeah true that, not sure how much better can the latency of running this locally be though. At least if there are no scaling issues lol. Fwiw though, you can still have this setup locally already, let me know if you want some pointers to try and build this out locally (you already have acces to the codebase anyways).

it's still far from simulation though, but I figure you could at least add the logic you need to replicate parts of it.

[sage vigil]

if the use case is arbitrage, I'm not sure simulation helps much - your result might really depend on the transactions that you're being applied with

[dark wing]

This is true, the primary use case was estimating clearing prices during liquidations for unwanted assets. That currently requires Horizon.

I'd expect arb folks could use this to help them check profitability, tho, even if it doesn't really get rid of the spam problems. (not an arb person, so 🤷‍♂️ )

[elder hamlet]

would this actually be useful? I could see how implementing this only for just a few selected ops is easier. Not sure if it would be worth it though, I think this is the first time someone asked for this.