Hi there,
I am a developer interested in getting started with writing some dApps on Algorand. Reading through the documentation since yesterday the following things still have me confused:
If a smart contract is funded by sending Algos to its address, there appear to be two ways to issue transactions from it to other addresses: Use a smart signature to sign the transaction(s), which will be able to transfer funds or assets when its logic function returns true, or use inner transactions within an application smart contract.
When a program is compiled in the Signature mode with PyTeal, can it still be deployed like a normal smart contract, or contract account, or can it only be used as a logic signature?
Can a smart contract act as an application and a contract account at the same time, that is, it can implement operations that access local/global data and also be used to sign transactions?
Since inner transactions exist, what is the use case for smart signatures? Wouldn’t it just be easier to implement an operation on a contract that uses inner transactions to send funds instead of validating external transactions that could pose as a potentially much greater security risk?
That’s true.
However, nowadays, except for very rare corner cases, the proper way is to only use inner transactions.
This allows much better composability (smart contracts cannot make inner transactions with logicsigs in particular).
I believe the binary would be compatible, though this is not recommended.
In addition, signature mode disables a lot of features (all those relying on state) making it almost impossible to write a real smart contract in Signature mode.
I’m not completely sure what would happen.
For sure, if an opcode using state is executed in a logicsig mode, it will fail.
What I’m not sure on the top of my head about is whether the mere existence of the opcode in the bytecode would make the program fail or not.
In any case, this is extremely strongly discouraged.
What use case are you considering?
Smart signatures / logic sigs were very useful for previous versions of TEAL/AVM that did not have inner transactions. Now that inner transactions are available, the only two use cases I am aware of are:
As contract account, smart signatures can be used when very costly operations need to be performed, such as ed25519verify or vrf_verify. A smart contract needing to perform such operations would require to be called (in a group of transaction) just after a transaction from the contract account. Importantly, this mechanism can only be used for smart contract methods that are not meant to be called from another smart contract, as smart contracts currently cannot issue inner transaction signed by a logic signature.
As delegated logic signature, smart signatures can be used in complex systems to delegate certain operations on an account to another signature key or another smart contract. Here are a few examples:
Delegation of the issuance of “change offline” transactions to a lower-security key to give the ability to very quickly send “change offline” transactions in case of a participation node issue.
Delegation of ASA transfers to a “hot key”. This allows to use of the Algorand blockchain to record token ownership in a custodial system. The actual keys of the custodial accounts can be kept in cold storage, while the system uses hot keys whose only ability is to transfer tokens between custodial accounts. This way, the system is no less secure than a centralized system with a centralized DB: in case of leak of keys, the only thing the attacker can do is to transfer the tokens incorrectly, but the attacker is not able to rekey accounts or steal Algos (if Algos are used for any purpose).
Note that the second use case can often be done using a smart contract and inner transactions. However, a delegated logic signature is often easier to write and use for that purpose.
I was not thinking of a particular usecase, more wondering about why existing apps like Tinyman appear to favor using a logicsig in connection with a call to an application instead of just creating inner transactions.
I have not seen however much examples on how to use it. When i search whole public github Search · InnerTxnBuilder.MethodCall · GitHub there are only 3 issues associated with it and no public code.
