Transaction executor is an important part of the protocol which takes care of the situations when a message is applied to an account. In this article, we give a basic description of the phases of transaction execution. You can find a more detailed description of the work with pseudo code in Evgeniy Shishkin's work Transaction Executor Functional Specification.
Understanding the work of this component is crucial for writing safe smart contracts.
Each transaction goes through 5 phases:
First, money is charged for storing code + contract data in the BC for the entire time passed since the previous transaction. If after this phase, delete_threshold < balance < 0, then the account gets suspended.
If delete_threshold > balance, the account gets deleted. Suspension is deleting the state and code of a contract, only its hash remains.
To resume a contract, you need to pay the debt and send the code + data at the moment of suspension. delete_threshold is a network parameter. For workchain 0, it is -0.1 VENOM.
Only for internal messages. The account balance is topped with value that came with a message. If the incoming message has the flag bounce: false, then Credit phase will be before Storage phase.
The execution of transaction. If an error occurs during this phase, we move to the Bounce phase, if the flag bounce: true. There is subtle point here: creating outcoming messages and computation is divided. If your transaction attempts to create outcoming messages, it just stacks intents for their creation into a special registry(c5). And the computation phase does not check that you have enough money to attach value to all these messages. It means that if you have 1 VENOM on your account, and you try to create two messages, each of which wants to send 0.8 VENOM, the computation phase will succeed, tvm exit code will be 0, and success: True.
In other words, the transaction will not crash at the moment on computation phase when you lack value for attachment. It will crash only in the case you run out of money to pay for gas or execution error is raised.
In this case those outcoming messages(and other actions) are created which were stored in the special registry at the computation phase. If you lack money to pay for outcoming messages, the transaction will be stopped and account state rolled back. Currently, if there are errors in the action phase, the bounce message is not created, although it should be according to the specification. In this situation you will have computation - success: true, action - success: false, abort: true.
There is also a special flag on the message creation that says that you should ignore this message if you lack money to create it.
Only for internal messages. If an incoming message had the flag bounce: true and there was some error in the computation
or action phases or contract is not deployed, an onError message is created in this phase (if there is still enough
money to pay for the message). It will call a service function onBounce of the original message sender contract.
All the remaining value of the message will be attached to it.