Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bounce message creation logic is inconsistent with the whitepaper #36

Open
unboxedtype opened this issue Oct 7, 2021 · 0 comments
Open
Assignees

Comments

@unboxedtype
Copy link

Hi!

In the whitepaper (https://ton.org/tblkch.pdf), the following text appears:

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

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?

@sv-91 sv-91 self-assigned this Oct 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants