Sorry no, Mandos is single-shard only

Writing "traceGas" = true at the start will show you how much gas is used and where, not sure we have some special stack trace option.

VecMapper means you have each item in a different place in storage, so the only way to take a subset is to iterate.

We're slowly moving away from the payment arguments, in hindsight they seem to have caused more confusion than necessary. There's a release on the way very soon which clears things up a little bit, stay tuned.

You need to make sure that the new storage layout is compatible with the old layout. It is also good practice to deploy your contract from a multisig so the upgradability is not a security vulnerability. In principle it is the same as having a proxy contract, only more convenient

It provides a very small boost in performance when working with managed types. You shouldn't worry too much about it though, Option works absolutely fine.

Behind the scenes `BigUint`s are actually `BigInt`s with restrictions. This means it will go through an i64 in the process, even if you declare it as u64. Just do `managed_biguint!(1_000_000_000_000_000_000) * 10` or something of the sort

ManagedBuffer::from(my_u64.to_bytes_be())

option.unwrap_or_else(|| sc_panic("should be some"))

It can, but making the setup can be tricky and it is not documented. I don't think anyone outside Elrond has ever done it

Make sure the nonce is the right one

Absolutely. With mandos you get the single-shard scenario, in which the callback always comes after the async call,

There's a lot of magic involved there, in the way callbacks currently work. It's made to look like a simple call, but the full process is that a callback proxy gets generated ( self.callbacks().my_callback() is a callback proxy in fact, it is a generated method), which serializes the proxy closure and saves it temporarily to storage. The callback then loads this data from storage and uses it. The syntax is what it is, it is the cleanest I could get. I would have loved to make it look like an actual Rust closure, but the compiler doesn't let me hack so deep.

Yes, we have #[callback_raw], but you need to know what you are doing. That one will catch all callbacks and does no processing at all

You could map users to their NFTs in storage, it's not expensive. It's not necessarily in the spirit of ESDT, more similar to how you would do it on Ethereum, but then you have control over them and can destroy them at will.

Results from sync calls no longer get added to your results, so you're only getting the results of the imnediate call. If A calls B calls C, A only gets results from B. If it A needs anything from C, B has to pass it explicitly

It's a ManagedBYTEArray, you can't put BigUint in it. Just use a ManagedVec

sc_panic!("your message") is the way. sc_error! has been removed.

SetMapper>

Start with some unit tests in Rust. Rust integration tests that generate Mandos coming soon. Until then, Mandos by hand. Finally, some snippets. Snippets are hard, so we usually leave then until the end

ManagedVec starts from 0, just like regular Vec

We have a formatter that does this elegantly, although I never tried to format tx data. Should be something like sc_format("message {}", args) but I need to check

Calling self.call_value().egld_value() in the callback should yield the amount you got

You'll have to serialize the representation by hand, there are some tricks you can use, like "u32:0|u32:5|u64:7" for example for a struct with 3 fields, 2x u32 and 1x u64

no, but still, you can try the nightly nightly-x86_64-unknown-linux-gnu

What was said about hashing is true for any blockchain. Elrond is just faster and cheaper in general, so for this task too.

Storage on the blockchain is expensive, what you usually do is to store a hash of the data on chain. You can use that hash to prove the data has not been tampered with. You can also store some metadata, indexes, etc. . .. depends on what you need with it

Free to use for anyone. There is only the transaction cost, but even that is zero if you deploy it on the testnet, which is enough to prove your worth and get the diploma.

You cannot import it because it is not a type, it is a generic (or type argument). It gets replaced automatically with ArwenBigUint in wasm mode and RustBigUint in debug mode. If you need it in a struct, you have to pass it on as a generic, e.g. MyStruct { x: BigUint ... }