ember niche
Original Q: is it possible to invoke host fns from a contract? (like the one for wrapping the token)
Now that I think of it I'm not even sure it would make any sense (I was thinking about swapping assets from classic to soroban)
after some thought: that shouldn't be possible since it'a a stellar-classic op right?
cosmic echo
yea invoking host functions from any contract would probably be a security issue 😆
wicked zodiac
Wrapping is actually a Soroban op. But the process of wrapping is creating a token contract for the asset. There is a host fn for it but it isn't currently exposed in the SDK because it's a rare function to use since you only need to call it once for an asset. You can call it from submitting a tx.
We really need to write up some docs on how to create the tx to submit it. I'll write up an example and share here tomorrow.
iron moss
I'm a bit confused by this question; most of the things you do within the contract is invoking the host functions. as for tokens in particular, isn't create_token_from_contract available for deploying your new tokens from contract? but specifically classic asset wrapping is indeed not available. just wanted to make sure that we're on the same page in terms of terminology
ember niche
I'm a bit confused by this question; most of the things you do within the contra...
I was referring to HostFunction::HOST_FN_CREATE_TOKEN_CONTRACT_WITH_ASSET, which I believed to be something that was not in Soroban's scope.
I guess I'm curious about why it's not available to be invoked directly from contracts
iron moss
the host functions invoked from tx are somewhat different from the host fns invoked from the contract (the ones exposed from the env). maybe we should name the ones invoked from tx differently in order to avoid confusion...
ember niche
Yeah I was actually not understanding well what was the difference between some of the fns described in the "invoking with stellar txs" and the ones invoked from the env.
iron moss
as for specifically depoying the various sorts of contracts from contracts, I wonder about the use cases. if there is a strong case for deploying contracts from contract on behalf of the user, I would like to do that within the auth framework instead of creating a host fn for every sort of id/source...
ember niche
But after all I think the current terminology is not wrong since afaik both are calling fns from the host-env (?)
iron moss
yes, but for clarity probably it would be better to have some unique names for the txs. not 100% sure about that, but even if we have 100% feature parity between what you can do from contract vs what you can do from tx, the interfaces still will be different
wicked zodiac
the host functions invoked from tx are somewhat different from the host fns invo...
maybe we should name the ones invoked from tx differently in order to avoid confusion
We had naming inconsistencies in the past and I don't think we were in a place of less confusion.
iron moss
I mean for tx I would probably not refer to host functions at all, as from the tx standpoint this is more of an implementation detail
wicked zodiac
Interesting, that seems like quite a departure from where we ended up with resolving to not add bespoke new ways to call things on the tx side, and to make it possible to call a set of host functions. I don't remember the full reasoning for how we got here, but I thought some folks debated this for a while before landing here.
What problem are we solving with a redesign of how host functions get called?
iron moss
well, I'm not sure what the discussion was, but the implementation ended up with a set of bespoke host functions that can only be called from the tx (and specifically not from the contract). tx also can benefit from typed an structured data (unlike the contract fns). since you need to know how to build xdr in order to send transactions in the first place, xdr interface seems more natural for tx