#Token Spec Refactor

23 messages · Page 1 of 1 (latest)

zealous hare
#

We have an issue open (https://github.com/stellar/rs-soroban-sdk/issues/727) to provide the token spec through the SDK instead of downloading or building a separate soroban_token_spec.wasm file like we require today. I want to gauge opinions on whether or not this change is required for when Soroban is released to mainnet, or if it's acceptable to make this change in a subsequent update. This isn't a change required to be feature complete, but I know downstream users have brought this issue up multiple times.

#

@light pebble @cinder forge @slow tendon

cinder forge
#

I'd say any non-protocol related change should be considered non-blocking as we can easily address it as a followup (as opposed to the changes that require a protocol upgrade)

zealous hare
#

I agree with you. I'm curious if there's anyone that thinks we should address before mainnet.

echo thicket
#

I personally don't think a compiled token spec would be useful within the rs-soroban-sdk. A separate package might make sense down the line (extension to soroban-token-spec?)

Either way, I expect it to be uncommon for the actual token spec WASM to be used on mainnet, since if some1 wants a basic token they are likely better off creating a Stellar Asset and using the Stellar Asset Contract.

light pebble
#

You currently need to depend on the soroban_token_spec.wasm to call a Stellar Asset Contract. Given that tokens are likely to be the most common element to use in contracts, and given the Stellar Asset Contract is built-in, and it implements the token interface, it feels to me like this should live in the soroban-sdk.

#

Protocol vs non-protocol is useful for determining what some folks need to be working on, but I think this is a significant impact on developer experience to need to go and find the .wasm file and import it into contracts to call SACs. Conceptually it doesn't make sense since there's no actual contract in the .wasm file. The current .wasm file was really just meant to be a holdover until we found a better way.

#

@zealous hare Is your question aimed at figuring out what this work priority should be?

rapid moon
zealous hare
mortal ledge
#

Given the importance of tokens in the Soroban ecosystem I feel strongly that we should add first-class support for them in the SDK. It's true that this is not a protocol change and can theoretically pushed post launch - but we are already putting a lot of resources into bringing developers into the ecosystem pre-launch and should consider their DX. @zealous hare what's the cost/complexity of adding this? On the surface it seems like a low hanging fruit

zealous hare
#

It shouldn't be that difficult. The question is if we should spend time on this given our timeline. I can put some time aside to see if this can be done quickly.

mortal ledge
#

@light pebble you've attempted this in the past - what's the lift here?

rapid moon
#

I do feel like it would be good to include that the interface wasm in the sdk, it sort of already is included... but, it seems like there should be some way to include the interface without importing the wasm... there have been times where something changed, and my soroban-token-spec build was outdated, and then i waste hours trying to debug a meaningless issue.

cinder forge
#

that's perfectly fair! though when the token interface has stabilized these issues shouldn't happen anymore

rapid moon
#

yeah I agree on that point too, once mainnet it would be very rare for the interface to change, if it even does...
The only time i faced those issues is due to the fast iteration of preview deployments, and in fact it only happened once that i wasted much time on it. the second time i remembered quickly.

I did try once to write the interface in my contract without importing it but it didn't work; and i figured it must just be something i didn't understand fully.

short whale
#

Currently it is also possible to include the soroban-token-spec crate as a dependency and then use it normally e.g.

let client = soroban_token_spec::TokenClient::new(&e, &token_id);
client.xfer_from(...);

Is there any downside to this approach?

rapid moon
#

i haven't ever tried that.

light pebble
#

We have found some issues with Rust importing cdylib crates into other crates. It's inconsistent, but sometimes it just won't work. And changing crates to support multiple crate types like rlib (allows importing explicitly) and cdylib at the same time unfortunately causes the Rust compiler to abandon some LTO (link time optimizations), which results in big .wasm files.

#

So, it might work sometimes to import soroban-token-spec, but other times no.

#

But I don't recommend adding rlib to any contract you write, as in some cases it'll cause the resulting .wasm file to be larger.