Hi!

In the compute_phase function, you try to deduct the gas_fee, and in case of an error (not sufficient balance), you just show the debug message, but it doesn't lead (well, not obvious, at least) to any kind of phase error.
Could you please point to the logic that recovers this situation?

if !acc_balance.grams.sub(&vm_phase.gas_fees)? {
   log::debug!(target: "executor", "can't sub funds: {} from acc_balance: {}", vm_phase.gas_fees, acc_balance.grams);
}

You also do the fee deduction from the msg_balance, but it may silently fail by the same reason, because .sub always
returns Ok(bool).
https://github.com/tonlabs/ton-labs-executor/blob/be2f1ec60e09857d8b8f489c1e79f000bba32269/src/ordinary_transaction.rs#L185

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?

Hi!

https://github.com/tonlabs/ton-labs-executor/blob/be2f1ec60e09857d8b8f489c1e79f000bba32269/src/transaction_executor.rs#L1058

There is a check for hdr.bounce flag set, but the message states the opposite:

https://github.com/tonlabs/ton-labs-executor/blob/be2f1ec60e09857d8b8f489c1e79f000bba32269/src/transaction_executor.rs#L1059

Is it intentionally done this way or is it a misspelling or is it an error?

Thanks!

Hi!

This skip boolean is used only once, during some error propagation code:

https://github.com/tonlabs/ton-labs-executor/blob/be2f1ec60e09857d8b8f489c1e79f000bba32269/src/transaction_executor.rs#L797

Are you sure this flag is fully implemented? In the old TON-1 node, there were at least 10 places they used the skip check. In your code, I see none.

Hi!

The processing logic of messages with SENDMSG_ALL_BALANCE seems incorrect to me. Could you please prove me wrong. Take in mind that Rust is not my native language, so I may miss something important.

During the processing of actions, starting at :
https://github.com/tonlabs/ton-labs-executor/blob/be2f1ec60e09857d8b8f489c1e79f000bba32269/src/transaction_executor.rs#L488

you put all messages with the flag into out_msgs0 collection, skipping their processing with 'continue' statment.

if (mode & SENDMSG_ALL_BALANCE) != 0 {
        out_msgs0.push((mode, out_msg));
        continue
}

After this initial iteration over the action list, you start to process out_msgs0 collection. But, this time, you also
skip messages with this flag set, using the same continue statement. You put them into out_msgs collection without processing.

 for (i, (mode, mut out_msg)) in out_msgs0.into_iter().enumerate() {
            if (mode & SENDMSG_ALL_BALANCE) == 0 {
                out_msgs.push(out_msg);
                continue
  }

This is strange, because the outmsg_action_handler contains the logic for processing messages with this flag set.
https://github.com/tonlabs/ton-labs-executor/blob/be2f1ec60e09857d8b8f489c1e79f000bba32269/src/transaction_executor.rs#L837

Am I missing something?

The error I'm getting when trying to build this is

error[E0432]: unresolved imports `ton_block::GasFlatPfx`, `ton_block::GasPrices`, `ton_block::GasPricesEx`
  --> .../ton-labs-executor-1c02eaf6bb19aa83/1f7e80b/src/blockchain_config.rs:17:5

See 20200710v2_build_sh.log for more details.

It is not clear to me how is it supposed to work. Let's look e.g. at ton_block::GasFlatPfx.

• Indeed, blockchain_config.rs refers to ton_block::GasFlatPfx.
• Cargo.lock suggests it should be defined in github.com/tonlabs/ton-labs-block.git#d658c653cb65eb42ad4492e7604c939b560f7ff0.
• Per this git search it does not seem to be defined there.

Hi!

My question belongs to the logic of the function:
https://github.com/tonlabs/ton-labs-executor/blob/be2f1ec60e09857d8b8f489c1e79f000bba32269/src/ordinary_transaction.rs#L62

Consider the following case:

1. We have an active account with some balance that is not enough to cover fwd_fee + storage_fee.
2. The incoming message is internal and has bounce flag unset and has some value attached to it.

After processing the storage phase, the account will become frozen due to condition (1):
https://github.com/tonlabs/ton-labs-executor/blob/be2f1ec60e09857d8b8f489c1e79f000bba32269/src/transaction_executor.rs#L235

Next, we go to the credit phase. It increases the balance of the account by the message value, but the account is still in
frozen state, you do not switch it back to Active, despite the fact that its balance is now non-negative and could cover the due expenses.

What is worse, you now go to compute phase and spend gas despite the fact that the account is frozen and has no state
that could be changed further (only state_init hash).

You the finalize the account state in:
https://github.com/tonlabs/ton-labs-executor/blob/be2f1ec60e09857d8b8f489c1e79f000bba32269/src/ordinary_transaction.rs#L237

Am I missing something? Is it by design?

Hi!

During the storage_phase execution, you refer to due_payment account field,
https://github.com/tonlabs/ton-labs-executor/blob/be2f1ec60e09857d8b8f489c1e79f000bba32269/src/transaction_executor.rs#L219

But it is not initialized anywhere. I also didn't find a place where the unpaid part of the storage fee is stored.

Am I missing something?