You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
4.2.5
...
Action phase - If the smart contract has terminated successfully (with exit code 0 or 1), the actions from the list are performed. If it is impossible to perform all of them—for example, because of insufficient funds to transfer with an outbound message—then the transaction is aborted and the account state is rolled back. The transaction is also aborted if the smart contract did not terminate successfully, or if it was not possible to invoke the smart contract at all because it is uninitialized or frozen.
Bounce phase — If the transaction has been aborted, and the inbound message has its bounce flag set, then it is “bounced” by automatically generating an outbound message (with the bounce flag clear) to its
original sender. Almost all value of the original inbound message (minus gas payments and forwarding fees) is transferred to the generated message, which otherwise has an empty body
Could you please clarify the following: 1) Is it the intentional deviation from the whitepaper specification? 2) If it is intentional, why it is done this way? 3) Am I correct that after unsuccessful action phase, th current implementation (commit 4cfc) does not revert the contract state to its original content? If not, could you please point out where it gets restored?
The text was updated successfully, but these errors were encountered:
Hi!
In the whitepaper (https://ton.org/tblkch.pdf), the following text appears:
It turns out, the bounce message has to be generated if any kind of error occurs, both on compute or on action phase. However,
in the executor, the logic is different. It creates the bounce message in case of the compute phase failure, but the action phase errors are mostly ignored. I came to this conclusion by looking at the line:
https://github.com/tonlabs/ton-labs-executor/blob/4cfc1dcd0b923ca8cdff88024f9bb2a2c3cdaa19/src/ordinary_transaction.rs#L224
Could you please clarify the following:
1) Is it the intentional deviation from the whitepaper specification?
2) If it is intentional, why it is done this way?
3) Am I correct that after unsuccessful action phase, th current implementation (commit 4cfc) does not revert the contract state to its original content? If not, could you please point out where it gets restored?
The text was updated successfully, but these errors were encountered: