#Bad simulation budget for new accounts

30 messages · Page 1 of 1 (latest)

solid orbit
#

Hello!

Wanted to report a weird (but consistent) error I am seeing on the Testnet when interacting with Blend.

If I create a new account and fund it with friendbot, the first transaction I simulate underestimates the required resource, and the transaction fails when I attempt to submit it for: operation byte-write resources exceeds amount specified.

See testnet tx -> e8cfb728cdabdaaec9b2b535eae697ca1ab72812e83fcc8fcbdd68832bfd3ed6

If I try again, the second simulation run returns the correct simulation values (and they remain consistent and correct after this).

See testnet tx -> ac7325ca96969f2d15f304e2c9f5681506391910785f124a325fb1a63e2fd924

It seems like there might be some missed cost for new accounts when simulating. Curious if anyone has seen this before?

frail abyss
#

what do you mean by 'new account' here? is that the new source account for tx, or new account use as an address somewhere during the contract execution?

#

(there indeed could be something missing, but it's not clear which type of ledger entry we're talking about)

solid orbit
#

I created the account via Friendbot, and that was the only action taken before the first transaction (e8cfb728cdabdaaec9b2b535eae697ca1ab72812e83fcc8fcbdd68832bfd3ed6)

hexed pollen
#

Could this be because the ledger entry for the balance is being created in that first tx, but the simulation isn't capturing that?

#

I assuming a balance is being created, I realize no one has said that's happening.

#

What's happening in that first tx?

solid orbit
#

One thing worth noting - the actual amounts charged look to match up with the second simulation.

In Tx1, it budgets 972 for writeBytes and charges 1024, causing the failure.

In Tx2, it budgets 1024 for writeBytes and passes.

#

Both transactions are the same, a deposit of XLM into a Blend pool. In turn, Blend creates an internal position entry to track this and transfers XLM via the native SAC from the user into itself.

frail abyss
#

so there shouldn't be a balance entry for the user

#

contract data entry, that is. there is only the account entry

#

my blind guess would be that the account entry size grew after fee has been charged

#

(not sure why would that be the case, but that's the only effect of the failed tx)

solid orbit
#

It would have to grow after the simulation tho, right? The amount charged is consistent in both the transactions.

frail abyss
#

yep, I was right

#

apparently we lazily create the AccountEntryExtension when we charge the fee

# 
State(
                            LedgerEntry {
                                last_modified_ledger_seq: 2621340,
                                data: Account(
                                    AccountEntry {
                                        account_id: AccountId(
                                            PublicKeyTypeEd25519(
                                                Uint256(157e719a735b136e419e6a1f8ab2ca7ba7a63383843805dfa26e86cf0fa70cf5),
                                            ),
                                        ),
                                        balance: 99999015436,
                                        seq_num: SequenceNumber(
                                            11258513737121792,
                                        ),
                                        num_sub_entries: 0,
                                        inflation_dest: None,
                                        flags: 0,
                                        home_domain: String32(
                                            StringM(),
                                        ),
                                        thresholds: Thresholds(01000000),
                                        signers: VecM(
                                            [],
                                        ),
                                        ext: V0,
                                    },
                                ),
                                ext: V0,
                            },

that's a 'fresh' account

#

and then we add the following in the failed tx:

ext: V1(
                                            AccountEntryExtensionV1 {
                                                liabilities: Liabilities {
                                                    buying: 0,
                                                    selling: 0,
                                                },
                                                ext: V2(
                                                    AccountEntryExtensionV2 {
                                                        num_sponsored: 0,
                                                        num_sponsoring: 0,
                                                        signer_sponsoring_i_ds: VecM(
                                                            [],
                                                        ),
                                                        ext: V3(
                                                            AccountEntryExtensionV3 {
                                                                ext: V0,
                                                                seq_ledger: 2621340,
                                                                seq_time: TimePoint(
                                                                    1700513316,
                                                                ),
                                                            },
                                                        ),
                                                    },
                                                ),
                                            },
                                        ),
                                    },
#

(can't fit the whole tx)

hexed pollen
#

AccountEntryExtensionV3 was added in CAP-21, and yeah, that's unavoidable. Records the last time the account entry changed, and it changed because its seq number bumped.

frail abyss
#

this is the Core logic (I wasn't even aware of it existing) and preflight has no clue about that as well

hexed pollen
#

The seq number is bumped even if the tx failed during apply.

solid orbit
#

Hm, didn't expect this to be tracked alongside the writeBytes tho?

frail abyss
#

of course, the fee is charged as well

#

we do, because you transfer XLM

#

so what happens is that core charges fee, entry grows, then we try to apply soroban tx and we read the modified account entry (which has grown)

solid orbit
#

ah, I follow now, makes sense. Is it possible for preflight to account for this?

frail abyss
#

sure. just need to open the issue and we'll address it. for the time being you could maybe add some flat amount on top of the preflight response

#

(I'll actually open the issue myself)

frail abyss