#Sandbox?

19 messages · Page 1 of 1 (latest)

lofty spruce
#

The soroban cli contains a sandbox mode where you can deploy contracts, invoke them, locally without a soroban-rpc, stellar-core, or any other infrastructure. It's original goal was that it could be an easy to use starting point for exploring contract development, and that it can support a decent amount of contract development (not dapp development).

A few folks have asked what the future of it should be, because its features have at times not been maintained consistently, and it's features don't support dapp development.

It's a good time for us to check in:

Are folks using the sandbox? If yes, what for? If no, what's missing? what are you using instead?

cc @sharp echo

golden shore
#

To be honest I have never used it. I think the standalone network is so easy to launch with the docker image that for me it just doesn’t make sense to use the sandbox when I can use the standalone and have a better “like production” environment… I think for local purposes the test environment with Rust is more than enough.

But I know some devs who are still using the sandbox

long lark
#

I guess it is a bit of a nice but from a security audit perspective it is pretty neat to have access to native code and step in directly from VSCode with lldb/gdb as well as explore variables etc

worn plaza
#

I think that the sandbox mode is great as long as it's complicated to start an rpc. However, if the cli was capable of starting a rpc for you, the motivation for the sandbox would go away. That being said - it might take more than a few tweaks to get there.

tranquil nexus
#

I agry with @golden shore: standalone is a better "like production" and is pretty easy to launch

oak gate
# lofty spruce The `soroban` cli contains a sandbox mode where you can deploy contracts, invoke...

Expecting the sanbox mode to behave as a standalone network/futurenet is unrealistic, just like we can't expect unit tests to. That's why no one (or almost) is not using it to try out their contracts since the implementation gets tested on unit tests and the actual on-chain interaction is better tested on futurenet or a standalone network. But, I think that a reference implementation of simulating a host-like vm instantiation and interaction is really helpful, for instance:

  • It can inspire more related work. Sandbox feels like your own programmable network and I'm very intrigued to start thinking on what advantages it could bring. For example, having a sandbox-alike implementation along with Mercury to achieve stuff like allowing to test out various contract implementations starting from a specific state obtained by the indexer database (for auditing, testing and testing out performance of new contract implementations matched with real input), this is just an idea btw and needs to be thought through.
  • It's very useful for testing out code from other SDKs without having to recreate the whole host implementation and without having to write cargo tests (I use it for Zig for instance).

I think it will ultimately end up being either a reference implementation or a tool that serves only very specific use cases, but I'd love for the sandbox to continue being maintained. As to what's missing, I don't think that there could be any tangible features that would make it competitive with an actual network for testing on-chain interactions.

harsh salmon
#

I haven't used the sandbox since the very beginning of Soroban. I mostly use the Rust testing env with both Rust contracts and compiled WASM ones, mainly because it allows you to mess with chain settings (like sequence number, timestamp, etc) to test contracts in more edge case scenarios.

Anything else benefits from being as production like as possible, where a standalone network / futurenet works better.

lusty coyote
#

I'm in the camp of never using it. Originally I thought it was awesome, until we got to Stellar integrations (e.g. SAC), fees, metering, errors, etc and then it became useless. In it's current state I really don't think it's useful and the work required to get and keep it up-to-date is very likely not worth it. Any questions it could answer are likely better answered on an actual network (wait times, fees, state expiration, Stellar integrations like the SAC, etc). For everything else it excels at, (speed, ease of use, inspectability, etc.) are better handled with native Rust tests. My vote is to kill it for now and put more energy into making it easier to standup standalone networks (like what @worn plaza suggests here: #1150948802107277392 message)

harsh salmon
oak gate
# lusty coyote I'm in the camp of never using it. Originally I thought it was awesome, until we...

I would say that it probably doesn't require much work to keep up to date, but it's also better to focus more energy in improving other stuff that will definitely be more used. I think that it might also be kept up by external contributions tbh. I generally would like the idea of being able to test contracts in sandbox by already having a snapshot of the entries I need and the sandbox would be a great starting point (but I'm not sure if or when I'll get around to do something like this).

lusty coyote
oak gate
surreal trout
#

Personally what I would like out of sandbox is some version of the current implementation of preflight linked to the Soroban-RPC. It would be nice to have a portable way to run preflights/read methods.

I agree that the CLI should only use the RPC. It's the only interface that matters to the dev process and production. And I think the effort should go toward a portable runtime that can lazily read in ledger entries and provide accurate preflight simulations.

In the sort term it's as simple as adding a command that invokes docker. Medium term it would be great to incorporate something like https://github.com/abiosoft/colima, a go library/binary for replacing docker desktop. For Unix users it would mean not needing to install anything to get the network going. However, it doesn't support windows.

lofty spruce
# oak gate I would say that it probably doesn't require much work to keep up to date, but i...

I generally would like the idea of being able to test contracts in sandbox by already having a snapshot of the entries I need
The Rust SDK allows you to load a ledger snapshot from a json file, so you can do what you describe with the Rust SDK as you can do with the CLI. I'd like us to also support auto-downloading production state for tests so you can test against a fork of pubnet with real data, but that needs to be explored more. That to say, we don't need CLI sandbox to make that happen.

oak gate
# lofty spruce > I generally would like the idea of being able to test contracts in sandbox by ...

that's actually awesome, I didn't know the sdk had support for that thanks for pointing it out! Regarding downloading production state for tests, I think that it's something that would fit well within an indexer since it allows you not to worry about having to load all the needed state (which would probably result in at least two requests: one for simulation and one or more for actually getting the data (depending on how much state you need to load)).

#

Though knowing that the sdk supports this, why was the sandbox implemented as it is now?

lofty spruce
#

However, to take some points I know @sly horizon made recently, which echo a lot of the comments above: The CLI sandbox mode is filling what has become a very small gap. On one side of the gap we have the Rust SDK test framework, which has become pretty feature rich and is easier to use in complex cases. On the other side of the gap we have the Quickstart Docker image, which is easy to run on most systems. The gap is small, and not as meaningful as what it was a year ago.

oak gate
#

yeah if the sdk supports working with snapshot files then I also agree that the sanbox as is does not bring much value.