#Can't deploy contract with soroban
53 messages · Page 1 of 1 (latest)
I tried to delve into the XDR for this. It seems the operation is hostFunction: [hostFunctionTypeUploadContractWasm] with a wasm-blob.
But the result AAAAAAAB2Y7/////AAAAAQAAAAAAAAAY/////AAAAAA= decodes as invokeHostFunctionResult: [invokeHostFunctionEntryExpired]
To me, that doesn't make sense, but perhaps some of the more brilliant minds here can help understand that 🙂
@storm zenith does it also happen if you deploy a different contract? I don't know if you have any available to try with. And/or try with a different source account. Just some thoughts from my to try eliminate certain causes
hmm, I tried with hello_world.wasm and it's fine. seem likes from my own contract.
Is it possible to share the contract code?
Yes, but it's skim_10. hmm. Can I send you in pm?
Sure, I can have a look
To update, the contract contained an external crate:
interface::Skirmish10Trait,
types::{DataKey, Error},
};```
The code for it is locally in interface.rs
My thought is that upon deploy, this can not be found and thus returns the Expired error. But I don't know if that makes sense, so please correct me
adding @wintry tapir just in case 🙂
invokeHostFunctionEntryExpired for wasm upload means that someone has already uploaded that exact wasm blob to the network and it has already expired. you can restore it, or, if you're lazy, you can modify your wasm a tiny bit to get written into a new entry
Oh cool that's a good insight
So what happens if the earlier install has not expired?
nothing
Yeah that makes sense
it would be wise to check if someone has uploaded your wasm before spending any money on trying to reupload it
(on the mainnet of course, on other networks you don't care much, I guess)
How would one check that?
use soroban-rpc to get the ledger entry. it's easy to identify - just do SHA-256 of your wasm
and put it into the ContractCode ledger key
Is that sha-256 of the wasm as it appears in the XDR (so base64) , or of the *.wasm file?
it doesn't appear in base64 in XDR
just wasm file
wasm is passed as array of bytes in XDR, base64 is probably applied on top of that in some clients
I think Laboratory does, at least when viewing the result XDR posted initially.
Thanks for the clarifications!
yeah, the canonical (wire) format for XDR is just bytes, no fancy encodings
Sorry to resurrect an old thread - say we find that the wasm has been uploaded by checking the ledger contract code. Is there any way to get the contract address? I'm trying to do a RestoreFootprint operation and it needs the contract address as one of the parameters (if i'm not mistaken)
well, if you want to restore a contract, you need to know its address
if you want to restore wasm, you need to know its hash
since one wasm can be shared by an arbitrary number of contracts, you can't go from wasm to contract address. you can keep an off-chain index though
but if there can be an arbitrary number of contracts for one wasm, why is it complaining that the wasm was already uploaded? How would you get into a state where there are multiple contracts for one wasm?
why is it complaining that the wasm was already uploaded?
I'm not sure who complains, you may try to upload the same wasm multiple times, but it will be a no-op after the first time
when you deploy a contract instance, you specify its wasm hash.
and arbitrary contracts can use the same hash
I'm not sure who complains,
the invokeHostFunctionEntryExpired error when trying to invoke UploadContractWasm
invokeHostFunctionEntryExpired means that the entry has expired, not that it's already uploaded. you need to restore it instead of recreating
CLI has a restore operation IIRC
i'm using the go sdk. i'm using the RestoreFootprint operation, but getting txInsufficientFee. I think i'm not setting the transactionData properly.
i'm trying to translate the js sdk from https://soroban.stellar.org/docs/fundamentals-and-concepts/state-expiration#restorefootprintop
you should increase your overall transaction fee then
it should be at least your soroban resource fee + 100 stroops
so, from that above doc, it sounded like I could take the transaction data from trying to UploadContractWasm to simulate a RestoreFootprint op and use that result.MinResourceFee for the actual RestoreFootprint sendTransaction
yeah, that's what i figured. So how do I construct a RestoreFootprint operation? There are only two fields:
- Source account (which i assume is my account) and
- Ext (which is the transaction data, but from where?)
this operation is a bit weird, but basically you just need to fill in the RW footprint in SorobanResources and the operation will restore any expired keys among those in the footprint (hence the restore footprint name)
so you're saying... int Ext.SorobanData.Resources.Footprint.ReadWrite.... put a LedgerKey with LedgerKeyContractCode? or LedgerKeyContractData?
Because if it's LedgerKeyContractData, I need the contract address (which I don't know, or don't want to keep off chain). But if it's LedgerKeyContractCode, that's easy, because I can calculate the hash of the wasm
LedgerKeyContractCode for the wasm, yes
for contracts, if you don't know the contract address, I suppose you don't want to restore it
great, thanks. and this operation also needs to be simulated (to get the fee and txnData) before being sent, correct?
yeah, it's a good idea to simulate it. to be perfectly clear, no operation has to be simulated, it's just for convenience. if you want to save some latency by not calling the soroban-rpc, you can get your hands dirty and compute the necessary resources/fees yourself. but most of the time that's probably a bad idea
good to know, thanks. And now after the RestoreFootprint has succeeded, I still need to Instantiate (create) the contract, correct? This is where the 1 wasm -> many contracts relationship comes in
yep