thanks again, it was really a great help for me.
i come back with another question here.
first thing is: i want to apply contract upgradeable in Algorand. i did know Algorand support this but does it have any limitation (like upgrade in EVM, the storage variable slot must be in order)? per Algorand design of storage, i believe that not the problem, right? How about remove variable or change variable name to some thing else, or change variable type (byte to int)? Does it have any consequence?
second thing is: does Algorand have some best practice for writing test? any platform supported yet (like truffle or hardhat in EVM)?
There is currently no official best practices. However, I would recommend looking at Algobuilder that provides contract unit testing and many tools facilitating deployment of smart contracts: https://algobuilder.dev/
by “the amount of storage cannot change”, i believe that it mean the contract cannot add or remore global or local variable. the number of global and local variable must be the same. it also mean that can not change global to local or a global variable to some other global one (different name, different type).
the only thing it can do is adding more logic to handle the storage. If it not, does AVM have plan to support that latter?
Changing the number of variables in local storage seems very very difficult because it would mean that the min balance of all the opt-in accounts increase.
For global storage, things may be possible in the future. Note that you can already simulate this by having accounts rekeyed to 0 opted in the application to provide local storage that can be essentially used as global storage.
talking about smart contract and future plan, there are something that Algorand different from other is that it does not have read function (like other VM). these read function is specially used for defi app since it doesnot rely on backend or cencerlize calculation.
Does AVM have plan to support that too?
i have this question for ASA. Per ASA design we can submit number of decimal place that we want to use. but i saw that the get balance opcode return uint64. so asume that the decimal is 18 then for the balance large than 20, it wont work? (20*1e18 > 2^64)
is that the limitation that almost token in Algorand support 6 decimals? Does Algorand team have further plan for this since uint64 for balance of token seem sometime not quite enough?
The decimal value is purely for display.
At the blockchain level, the only thing that matters is the number of base units without the decimal point.
This number is always represented as an uint64 and there is no plan to extend this.
Concretely, in your case, you just could not even create an asset that allows balance over 20, as the total number of units would be about 2^64, which means it does not fit an uint64.
Do you have a use case that would require such precision?