[FA] remove withdraw event when burn #15357

lightmark · 2024-11-21T21:44:47Z

Description

We don't emit event when burn APT coin, neither should APT FA.
Now each txn burn gas fee from APT FA, we see a withdraw event for this.

We first remove this event to facilitate the exchanges to recognize deposit.

How Has This Been Tested?

simple refactoring.

Type of Change

Which Components or Systems Does This Change Impact?

trunk-io · 2024-11-21T21:44:51Z

⏱️ 40m total CI duration on this PR

Job	Cumulative Duration	Recent Runs
rust-move-tests	13m	🟩
rust-move-tests	8m	🟥
rust-move-tests	7m	🟥
execution-performance / test-target-determinator	4m	🟩
rust-cargo-deny	3m	🟩 🟩
check-dynamic-deps	1m	🟩 🟩
semgrep/ci	1m	🟩 🟩 🟩
general-lints	1m	🟩 🟩
file_change_determinator	23s	🟩 🟩
permission-check	6s	🟩 🟩
permission-check	4s	🟩 🟩

_{settings ⋅ feedback ⋅ docs ⋅ learn more about trunk.io}

aptos-move/framework/aptos-framework/sources/fungible_asset.move

igor-aptos · 2024-11-21T21:59:53Z

aptos-move/framework/aptos-framework/sources/fungible_asset.move

@@ -1057,8 +1069,6 @@ module aptos_framework::fungible_asset {
                assert!(store.balance >= amount, error::invalid_argument(EINSUFFICIENT_BALANCE));
                store.balance = store.balance - amount;
            };
-


weren't folks complaining that there wasn't a Withdraw before? after migration now it is consistently to be always there?

also changing this after migration has started seems even more confusing? maybe we should create WithdrawForGas event and emit that one instead, so callers can choose what to do with it?

@movekevin for thoughts

Part of the reason I break so many tests is due to this new event.
I don't know who complained there was not a withdraw before.
cc @kent-white @gregnazario for your thoughts as well.

It seems mint_and_refund also has a deposit event... I am not sure whether we should have this PR now.

can the caller know when (or how much) of the gas fee has been paid by coin (as so has no event) vs fa (and so has this event).
If that cannot be distinguished, then users cannot appropriately adjust the balances. so we should try to address that, in the cleanest way possible

coin gas fee is implicit. I think we can only know from FeeStatement.

lightmark · 2024-11-21T22:57:36Z

I create two events to presents gas burnt and gas refunded.

igor-aptos

cc @runtian-zhou for thoughts here, as you are changing these files for permissions as well

separation here also makes a permission checks more clearer - _for_gas methods have a different permission check (all the way in transaction_validation), and other methods have permission check here. And events here also then distinguish the permission needed, which is cool

cc @movekevin and @davidiw for thoughts on this, as this is pretty big change logically

aptos-move/framework/aptos-framework/sources/aptos_account.move

igor-aptos · 2024-11-22T18:28:50Z

aptos-move/framework/aptos-framework/sources/coin.move

@@ -779,9 +779,12 @@ module aptos_framework::coin {
            burn(coin_to_burn, burn_cap);
        };
        if (fa_amount_to_burn > 0) {
-            fungible_asset::burn_from(
+            fungible_asset::address_burn_from_for_gas(


burn_from is a public function that might be called from anywhere? we would need separate public(friend) for_gas variant and leave the public to emit regular events?

address_burn_from_for_gas is the separate friend function.
Now burn function does not emit events.

no I meant coin::burn_from

if some other coin type has BurnCapability and calls this, it will emit wrong event.

aptos-move/framework/aptos-framework/sources/fungible_asset.move

runtian-zhou

I don't think this would help the permissions? As there were no signers involved at all. Seems to me a purely functional change for FA

aptos-move/framework/aptos-framework/sources/fungible_asset.move

davidiw · 2024-11-22T19:19:54Z

looks like this could be very expensive perf wise -- are we unable to compute this? why do we need this?

lightmark · 2024-11-22T20:17:06Z

I don't think this would help the permissions? As there were no signers involved at all. Seems to me a purely functional change for FA

it will have signers. I will refactor a little bit after AA code.

lightmark · 2024-11-28T03:30:04Z

looks like this could be very expensive perf wise -- are we unable to compute this? why do we need this?
which is expensive? if you're referring to event, the status quo is we emit an event when burn gas. This PR just replace it with another event.

Also, an exchange asked us how they can tell the difference between migration txn depositing FA or transfer depositing FA. I think this PR can solve their issue.

github-actions · 2024-12-05T21:16:31Z

✅ Forge suite `framework_upgrade` success on `c2969f0b0ecd826aa1516a386aed59496a247958` ==> `b03ae016708fe3478783aad04b61afd632a2dcad`

Compatibility test results for c2969f0b0ecd826aa1516a386aed59496a247958 ==> b03ae016708fe3478783aad04b61afd632a2dcad (PR)
Upgrade the nodes to version: b03ae016708fe3478783aad04b61afd632a2dcad
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1311.13 txn/s, submitted: 1313.55 txn/s, failed submission: 2.43 txn/s, expired: 2.43 txn/s, latency: 2261.68 ms, (p50: 2100 ms, p70: 2400, p90: 3400 ms, p99: 5300 ms), latency samples: 118940
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1388.59 txn/s, submitted: 1394.56 txn/s, failed submission: 5.98 txn/s, expired: 5.98 txn/s, latency: 2116.57 ms, (p50: 1800 ms, p70: 2100, p90: 3000 ms, p99: 4900 ms), latency samples: 125460
5. check swarm health
Compatibility test for c2969f0b0ecd826aa1516a386aed59496a247958 ==> b03ae016708fe3478783aad04b61afd632a2dcad passed
Upgrade the remaining nodes to version: b03ae016708fe3478783aad04b61afd632a2dcad
framework_upgrade::framework-upgrade::full-framework-upgrade : committed: 1450.21 txn/s, submitted: 1453.39 txn/s, failed submission: 3.18 txn/s, expired: 3.18 txn/s, latency: 2123.65 ms, (p50: 2100 ms, p70: 2100, p90: 2700 ms, p99: 4200 ms), latency samples: 127640
Test Ok

github-actions · 2025-01-07T03:03:31Z

✅ Forge suite `realistic_env_max_load` success on `f002e32342faea595bda7448fc580ab8d389a617`

two traffics test: inner traffic : committed: 14951.76 txn/s, latency: 2659.08 ms, (p50: 2700 ms, p70: 2700, p90: 2700 ms, p99: 3000 ms), latency samples: 5685040
two traffics test : committed: 100.00 txn/s, latency: 1308.60 ms, (p50: 1300 ms, p70: 1400, p90: 1400 ms, p99: 1600 ms), latency samples: 1780
Latency breakdown for phase 0: ["MempoolToBlockCreation: max: 1.567, avg: 1.525", "ConsensusProposalToOrdered: max: 0.288, avg: 0.286", "ConsensusOrderedToCommit: max: 0.297, avg: 0.292", "ConsensusProposalToCommit: max: 0.583, avg: 0.578"]
Max non-epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 0.88s no progress at version 36189 (avg 0.19s) [limit 15].
Max epoch-change gap was: 0 rounds at version 0 (avg 0.00) [limit 4], 0.54s no progress at version 2292267 (avg 0.54s) [limit 16].
Test Ok

github-actions · 2025-01-07T03:12:17Z

✅ Forge suite `compat` success on `6593fb81261f25490ffddc2252a861c994234c2a` ==> `f002e32342faea595bda7448fc580ab8d389a617`

Compatibility test results for 6593fb81261f25490ffddc2252a861c994234c2a ==> f002e32342faea595bda7448fc580ab8d389a617 (PR)
1. Check liveness of validators at old version: 6593fb81261f25490ffddc2252a861c994234c2a
compatibility::simple-validator-upgrade::liveness-check : committed: 16741.43 txn/s, latency: 2065.73 ms, (p50: 2000 ms, p70: 2100, p90: 2500 ms, p99: 4100 ms), latency samples: 549380
2. Upgrading first Validator to new version: f002e32342faea595bda7448fc580ab8d389a617
compatibility::simple-validator-upgrade::single-validator-upgrading : committed: 7050.40 txn/s, latency: 4288.80 ms, (p50: 4900 ms, p70: 5200, p90: 5400 ms, p99: 5400 ms), latency samples: 130840
compatibility::simple-validator-upgrade::single-validator-upgrade : committed: 6890.91 txn/s, latency: 4939.82 ms, (p50: 5300 ms, p70: 5400, p90: 5600 ms, p99: 5800 ms), latency samples: 234420
3. Upgrading rest of first batch to new version: f002e32342faea595bda7448fc580ab8d389a617
compatibility::simple-validator-upgrade::half-validator-upgrading : committed: 7764.66 txn/s, latency: 3870.38 ms, (p50: 4400 ms, p70: 4700, p90: 4800 ms, p99: 4900 ms), latency samples: 146520
compatibility::simple-validator-upgrade::half-validator-upgrade : committed: 7736.49 txn/s, latency: 4371.35 ms, (p50: 4700 ms, p70: 4800, p90: 4900 ms, p99: 5400 ms), latency samples: 256440
4. upgrading second batch to new version: f002e32342faea595bda7448fc580ab8d389a617
compatibility::simple-validator-upgrade::rest-validator-upgrading : committed: 13364.67 txn/s, latency: 2091.14 ms, (p50: 2100 ms, p70: 2400, p90: 3000 ms, p99: 3200 ms), latency samples: 236240
compatibility::simple-validator-upgrade::rest-validator-upgrade : committed: 13135.60 txn/s, latency: 2384.28 ms, (p50: 2200 ms, p70: 3000, p90: 3200 ms, p99: 3300 ms), latency samples: 432660
5. check swarm health
Compatibility test for 6593fb81261f25490ffddc2252a861c994234c2a ==> f002e32342faea595bda7448fc580ab8d389a617 passed
Test Ok

igor-aptos

@runtian-zhou can you review as well, and also check how it interacts with your permissions PRs?

lightmark requested review from davidiw, movekevin and wrwg as code owners November 21, 2024 21:44

lightmark requested a review from igor-aptos November 21, 2024 21:49

igor-aptos reviewed Nov 21, 2024

View reviewed changes

lightmark force-pushed the lightmark/no_withdraw_event_from_burn_fa branch from 4760bba to ab06352 Compare November 21, 2024 22:55

lightmark changed the title ~~[FA] no withdraw event for burn~~ [FA] s/withdraw/gasburn/ event & s/deposit/gasrefunded/ event Nov 21, 2024

lightmark requested review from kent-white and gregnazario November 22, 2024 16:35

igor-aptos reviewed Nov 22, 2024

View reviewed changes

runtian-zhou reviewed Nov 22, 2024

View reviewed changes

aptos-move/framework/aptos-framework/sources/fungible_asset.move Show resolved Hide resolved

aptos-move/framework/aptos-framework/sources/fungible_asset.move Outdated Show resolved Hide resolved

aptos-move/framework/aptos-framework/sources/fungible_asset.move Outdated Show resolved Hide resolved

lightmark force-pushed the lightmark/no_withdraw_event_from_burn_fa branch 2 times, most recently from a8d769c to 565ab43 Compare December 2, 2024 18:56

lightmark requested a review from junkil-park as a code owner December 2, 2024 18:56

lightmark force-pushed the lightmark/no_withdraw_event_from_burn_fa branch from 565ab43 to 09dd0bb Compare December 2, 2024 21:24

lightmark requested review from msmouse and grao1991 as code owners December 2, 2024 21:24

lightmark force-pushed the lightmark/no_withdraw_event_from_burn_fa branch from 09dd0bb to 311023e Compare December 3, 2024 22:09

lightmark enabled auto-merge (squash) December 3, 2024 22:34