Hello,
I have a question regarding the protocol (current implementation) :
In which of the 3 steps (proposal, soft vote and certify vote) is there TEAL code execution ?
And in a normal/nominal round, is there only one block which has its TEAL executed in a given node and step ?
I’ll try to answer, but I’m not sure I follow your questions precisely.
First, there are two kinds of TEAL execution, 1) programs executed in logicsigs, and 2) programs executed in ApplicationCall (“appl”) transaction.
Case #1 Logicsigs - These are explicitly designed to be stateless with respect to the blockchain’s state. So, logicsig programs are executed by a node only once, and that answer can be relied on forever. That execution occurs in one of two places.
Transaction arrival - First, when a potential transaction arrives at a node (this would be before being put into a proposed block, it is coming from another node, or from REST API). If the logicsig passes, the transaction can move on to the queue used to prepare potential proposals, and can be forwarded to other nodes (who will process it the same way.).
OR
Proposal arrival - if a transaction arrives for the first time to a node in a proposed block (by bad luck, the node looking at the proposed block has never seen this transaction before) - then its logicsig must be executed as part of block validation. These are, not coincidentally, also the exact places that normal cryptographic signatures are evaluated on transactions.
Case #2 ApplicationCall transactions - consider again the two subclasses above.
Transaction arrival - If the transaction arrives as a possible transaction to be proposed, it undergoes signature evaluation as described above, and then TEAL associated with the called app is run. If it fails, the txn is discarded. If it succeeds, it gets onto the queue for potential proposal (and can be forwarded). Here, unlike logicsigs, the decision is not final. If the txn is on that queue when a proposal arrives, and that proposal does not have the txn in it, then it can’t simply be blindly kept in the queue. It must be re-evaluated, since it relies on blockchain state that may have changed. (This is similar to how even a simple “pay” transaction must be reconsidered - maybe the sender no longer has sufficient funds.)
Proposal arrival - If the transaction arrives in a proposal, it must be evaluated even if it is already in the receiving node’s txn queue. Unlike with logicsigs, app calls are dependent on state changes, so the proposal’s app calls (and again, even pays) must be executed in the order they arrive in the proposal.
3 Likes
Thanks a lot @jannotti for this very detailed and informative answer !