Add support for Soroban as a target

[tomerweller]

Soroban is a new smart contracts platform built by and for the Stellar ecosystem. The Soroban environment utilizes Parity's WASMI runtime and is written in rust. The main contract developer SDK is also written in Rust.

Stellar is one of the most active L1 blockchains by TPS (according to realtps.net) and is connected to a global network of on and off ramps, including hundreds of thousands of cash agents (through moneygram). These factors make Soroban especially appealing for smart contract developers.

[seanyoung]

Very interesting. I think it's entirely possible to add support to Solang for Soroban contracts runtime.

This would require the following steps:

• Add new target Soroban
• Solang sema should have special rules for Soroban builtins
• Write XDR encoder/decoder for Solang (at least from my cursory reading, it looks like Soroban uses the XDR encoding)
• Solang emit should implement new target SorobanTarget and handle low level code like host function calls
• Add whole bunch of tests and documentation

Now right now I don't think any of the maintainers have time to work on this, but we certainly are always available to help anyone with this. We have a call every weekday at 13:00 UTC on Hyperledger discord server #solang-meetup

[leighmcculloch]

@seanyoung Thanks for an outline into what work would be required.

@JakeUrban @graydon and I spent a small amount of time last week exploring what would be involved. We wrote (hacked together) some changes to get the most basic contract executing on Soroban, to help us understand how compatible Soroban would be with Solang, and Solidity, and identify blind spots.

I tried to capture that in comments on:

• 1138

There are some problems that we'd have to come up with a story for:

• Solidity supports function overloading, Soroban does not.
• ~Soroban functions need to be max 10 characters long in name, so appending parameter lists wouldn't work. We might need to hash function names, or suffix them.~ (See https://github.com/hyperledger/solang/issues/1129#issuecomment-1684243124)
• Solidity has guaranteed to execute constructors, but Soroban currently does not. We'd probably need to map them to some regular functions named init.... This might change.
• Solidity has multiple return values. Soroban doesn't support multiple return values in WASM. We would probably address this by placing the return values into a Soroban Vec.
• ~Solidity has u256 values, but Soroban only supports up to 128-bit values. We could map them to Soroban's Bytes but that might be inefficient.~ (See https://github.com/hyperledger/solang/issues/1129#issuecomment-1684243124)
• Solang's WASM emitting assumes there's a fixed set of exported functions like call and deploy, but Soroban contract functions are exported as is, so we'd need to modify some assumptions so that dynamic exports are enabled. Alternatively, Solang Soroban contracts could have a single point of entry, although Solang built contracts wouldn't get the same code generation for clients that other Soroban contracts get.
• Solang assumes memory is imported, but in Soroban contracts memory is exported.
• Soroban contracts always accept and return i64 values that contain type information and then either the value for small values (e.g. u32) or a handle to the value in the host system. It'd need to be decided if it is better to inject the instructions for unpacking them, or provide a bitcode stdlib of sorts.

[seanyoung]

@leighmcculloch very thorough and interesting!

So it looks like due differences with ethereum, it might be prudent to make Solidity on Soroban a slightly different dialect which does not support 256 bit integers. The contract could enforce that the constructor is called first (for non-pure functions) by setting some sort of flag.

Looks to me creating a Soroban target for Solang is entirely possible!

[xermicus]

@leighmcculloch @tomerweller what's the status of this; are you planning to go forward here?

[leighmcculloch]

Since I posted the list of interesting issues to solve, a couple things have changed in Soroban that makes it an easier fit I think:

• Soroban supports u256 values now, so there wouldn't be a need to work around that ommission.
• Soroban functions are no longer limited to 10 characters, so there wouldn't need to be work arounds for that.

I updated the list in https://github.com/hyperledger/solang/issues/1129#issuecomment-1402338915.