Rust special-account storage phase diverges from C++ and can make mixed validators derive different state roots

[EmelyanenkoK]

Summary

Rust short-circuits the storage phase for special accounts and collects no storage fees at all. C++ does not. C++ still computes and collects storage fees for special accounts, and it still clears previously accumulated due_payment when the balance covers it. Only freeze/delete transitions are treated specially there.

Because storage fees and due_payment feed directly into replayed transaction output and account state, this discrepancy is consensus-critical.

Affected code

• Rust: rust_implementation/ton-rust-node/src/executor/src/transaction_executor.rs:163-189
• Rust: rust_implementation/ton-rust-node/src/vm/src/smart_contract_info.rs:104-112
• C++: crypto/block/transaction.cpp:1056-1123

Rust/C++ discrepancy

Rust exits early for is_special:

if is_special {
    return Ok(TrStoragePhase::with_params(
        Coins::zero(),
        acc.due_payment().cloned(),
        AccStatusChange::Unchanged,
    ));
}

That means Rust does not:

• compute current storage fees
• add prior due_payment
• debit balance for storage fees
• clear due_payment when it is covered

C++ still performs fee accounting for special accounts:

• computes current storage fees
• adds previous due_payment
• collects what can be collected
• clears due_payment when fully covered

The special-account exemption in C++ only suppresses freeze/delete consequences and last_paid handling. It is not a full storage-phase bypass.

Trigger

The discrepancy is reachable on any special-account transaction where storage accounting is non-zero, including:

• tick-tock execution
• ordinary execution paths that run on special accounts
• cases with existing non-zero due_payment
• cases where current storage fees accrued since last_paid

This does not require an invalid block or malformed transaction. Honest chain activity is enough once a special account reaches one of those states.

Why this can stop a mixed Rust/C++ network

For the same special-account transaction, Rust and C++ can derive different values for:

• storage_fees_collected
• storage_fees_due
• account balance after storage phase
• persisted due_payment
• TVM-visible DUEPAYMENT in the contract context
• final account state and state root

Because Rust also exposes account.due_payment() through SmartContractInfo, the discrepancy is not limited to the storage-phase descriptor. It can change later compute/action behavior inside the same transaction.

That makes the replay result implementation-dependent:

• a Rust validator replaying a C++-produced block can compute a different transaction result and reject the block
• a C++ validator replaying a Rust-produced block can do the same in the opposite direction

In a mixed validator set, a single block containing such a special-account transaction can split validator votes and stop consensus. No attacker is required if the relevant special-account state occurs naturally; an attacker only makes the trigger easier.

Suggested fix

Remove the Rust early return for is_special.

Rust should match C++ by:

• computing storage fees for special accounts
• adding existing due_payment
• debiting balance
• clearing due_payment when covered
• keeping only the C++ special-case behavior for freeze/delete handling and related status transitions

Suggested regression test

Build a replay fixture for a special account with non-zero storage debt or accrued storage fees.

The test should compare Rust and C++ on:

• TrStoragePhase
• balance after transaction
• persisted due_payment
• final transaction/state hash

Rust should match the C++ result exactly after the fix.

[bvscd]

The issue report is incorrect — there is no consensus-critical discrepancy.

The key is at following line in the C++ code:

  if (now <= last_paid || !last_paid || is_special || pricing.empty() || now <= pricing[0].valid_since) {                                                                                                                                           
      return td::zero_refint();                                                                                                                                                                                                                     
  } 

Here's the full chain:

1. C++ compute_storage_fees: returns zero for is_special accounts — the check is_special is right there in the early-return condition
2. C++ prepare_storage_phase: computes to_pay = compute_storage_fees(...) + due_payment — since fees are zero, to_pay equals just due_payment
3. For special accounts, due_payment is also zero because it's only set inside a !res->is_special guard — special accounts never accumulate due_payment
4. So to_pay is zero, hitting the branch at line: fees_collected = fees_due = zero
5. The only special-account-specific behavior left is line: last_paid = (is_special ? 0 : now) — keeping last_paid at 0

Both implementations produce the same result for special accounts: zero fees collected, zero fees due, no balance change, no status change. The Rust early return is a valid optimization that skips computation guaranteed to yield zeros. The due_payment field for a special account is always None/zero because it can never be set (the C++ code guards the assignment with !is_special).

[bvscd]

Close as fixed

[EmelyanenkoK]

I disagree:

• It is correct that C++ does not accrue new storage fees for accounts that are already special, because compute_storage_fees() returns zero when is_special is true in crypto/block/transaction.cpp:788.
• But that does not eliminate the discrepancy, because prepare_storage_phase() still charges inherited due_payment: to_pay = compute_storage_fees(...) + due_payment in crypto/block/transaction.cpp:1060.

Why the discrepancy still exists:

• Rust exits immediately for is_special and returns storage_fees_collected = 0, storage_fees_due = acc.due_payment(), with no balance change in /src/executor/src/transaction_executor.rs:163.
• In C++, due_payment is part of serialized account state and is parsed/stored without any special-account invariant in crypto/block/transaction.cpp:282, crypto/block/transaction.cpp:3670, and crypto/block/transaction.cpp:4053.
• "Special" is not inherent property of the account: for instance TON Teleport bridge was first deployed and then later became special. It is possible (not 100%) that if contract is not deployed, before becoming special, that it is possible to send 1 nanoton, create state which will start collect fees, and then deploy in such a way that due_payment will be > 0.

So, I believe that a valid chain state can have is_special == true and due_payment > 0.

In that state, C++ and Rust diverge immediately:

• If balance covers the debt, C++ collects due_payment, decreases balance, and on modern global versions clears due_payment in crypto/block/transaction.cpp:1069.
• Rust collects nothing and leaves both balance and due_payment unchanged in rust_implementation/ton-rust-node/src/executor/src/transaction_executor.rs:163.
• If balance does not cover the debt, C++ still collects the whole balance and reports remaining fees due in crypto/block/transaction.cpp:1080; Rust still collects nothing.

That is still consensus-critical, because it changes transaction fees, balances, due_payment, TVM-visible state, and therefore replayed state roots.