I really can not understand why we need stateless and stateful smart contracts at the same time. Stateful contracts can do everything stateless contracts can do and I don’t think there is any considerable advantages in having stateless and stateful contracts separately. (for resource management or anything…)
Worse than this is that Algorand protocol does not allow stateful contracts to approve or reject transactions. Why such a design choice has been made? Stateful contracts need to be able to validate transactions. That’s a necessary feature. currently in Algorand for validating a transaction by a stateful contract we have to use an atomic transaction and link that statful contract to a stateless contract. This process is complex and makes programming difficult with no reason.(just take a look at the article which explains how to do that!)
Unfortunately the story does not end here. for authorizing a transaction with a stateless contract the whole byte code of that contract needs to be signed and added to the transaction! that means for every transaction a new copy of that contract code will be added to the blockchain! why don’t we give the contract an id and use that id instead? this is really a waste of resources. Storage is a critical resource in blockchains. why would you use blockchain storage for keeping thousands copies of a contract?
While I’m not going to comment on the way Algorand built things, I will point you towards Reach (https://docs.reach.sh) it removes all of this difficulty.
I know that you are trying to do this manually and probably isn’t the answer you are looking for, but just hoping I can help with what you are trying to accomplish.
I was hoping that I would get an answer from Algorand’s team about this one…
We are always looking for ways to improve smart contracts. One of our primary design goals for any feature we add is to maintain or improve throughput, which currently is 1000 tx/sec with transaction finality of fewer than five seconds. This means we have to restrict some things in our smart contracts (size and opcode cost). We do not want a scenario where an app can be developed that does “anything” but kills throughput for everyone else. By adding limitations on both stateful and stateless contracts we can still give developers the ability to create unique applications while maintaining network performance.
Stateful and Stateless contracts are executed at different times. Stateless contracts can be run in parallel and in advance of block assembly. Stateful contracts are executed during block assembly which typically takes 200ms. The block assembly time slot is tightly controlled and must be for performance and ledger reasons. This is why Stateless contracts can be bigger and offer more opcode budget.
Not all operators can be used in both stateful and stateless currently. One, in particular, is ed25519verify which does signature verification. It is extremely expensive and we don’t allow it to be used in stateful contracts. In fact that one call takes about twice the amount of time to run than one stateless contract call. Smart Contract limitations are shown here https://developer.algorand.org/docs/features/asc1/teal/#operational-cost-of-teal-opcodes
By allowing linking of stateless and stateful contracts using atomic transfers, we give developers the ability to still create larger more complex applications without impacting performance. The team is working on many performance-related features and hope to offer even more in the future. I hope this helps in understanding. Your feedback is appreciated.
Thank you for your response.
I still can’t understand why stateful smart contracts should not have a corresponding Algorand address…
In my opinion, stateful smart contracts could have an Algorand address And like a stateless smart contract, they could govern their address. In other words, protocol could require that any transaction which has a stateful smart contract’s address as its sender be approved by the smart contract’s logic. (also its better to require the same for transactions with a smart contract’s address as their receiver) In this way, for simple operations like depositing money to a stateful smart contract, we don’t need atomic transactions.
Atomic transactions are really a useful feature of Algorand’s blockchain but they should not be needed for performing simple operations.
Also I think current LogicSig structure is inefficient, because it contains the whole byte code of the stateless smart contract. Every transaction which needs that contract will contain a copy of it, wasting bandwidth and memory. This happens because currently there is no way for installing and storing a stateless smart contract into the Algorand’s blockchain and we have to re-upload the contract code every time we want to use it.
Obviously, executing a stateless smart contract has a lower cost since we don’t need to read the state data from the ledger. but we should not forget that usually a stateless smart contract is a part of a payment transaction. Therefore we still need to load the balance data from ledger to be able to validate that transaction.
In terms of parallel processing, stateful contracts can be run in parallel too, because a contract has read-only access to other contracts data and it can not modify another contract’s state.
When we have a stateless smart contract and a stateful contract which only uses 4 bytes of storage, how different are they? In my opinion a smart contract which only uses a few bytes of storage is similar to a stateless contract. But a contract with 100Kb state size is obviously different, therefore categorizing contracts into stateless and stateful groups is not enough and it is not useful. We need to impose some type of cost on contracts based on the exact amount of storage/memory they’re using.
Thanks for your response. You make some interesting points and we are definitely looking at the areas of cost and when that calculation is done as well as options that improve contract accounts. We appreciate your feedback and suggestions.
Algorand is definitely considering a proposal to give stateful contracts control over an associated account. In analogy to stateless contracts, they might have authority over the address that is the hash of their source code combined with the creating account. (So that multiple instances of the same code might exist.)
Your proposal of allowing a logicsig to reference an installed stateless app is interesting. It would save space for people using complicated, repeated logicsigs. Do you use the same large logicsigs repeatedly? We tend to think that logic sigs are both small (maybe just to check a couple values) and used only once or few times (an escrow account that ceases to exist after being used). In such cases, there’s little to be gained by asking users to install a stateless script, and then reference it from a later transaction.