-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Redistributing fees #4967
Redistributing fees #4967
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall looks great!
aptos-move/framework/aptos-framework/sources/fee_distribution.move
Outdated
Show resolved
Hide resolved
1f72fd0
to
03c6175
Compare
aptos-move/framework/aptos-framework/sources/reconfiguration.move
Outdated
Show resolved
Hide resolved
cc @zekun000 @movekevin @junkil-park - this draft has now all the APIs (I hope). I am adding e2e tests at the moment, and in particular tests that include reconfigurations that remove validators. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First pass. This is great so far and most comments are minor and more about code structuring. There's one edge case that we have discussed and still need to resolve: what happens if there are remaining undistributed fees because the proposer leaves the validator set in the same block that they propose. This can happen for blocks that contain governance proposal execution.
aptos-move/framework/aptos-framework/sources/reconfiguration.move
Outdated
Show resolved
Hide resolved
aptos-move/framework/aptos-framework/sources/transaction_fee.move
Outdated
Show resolved
Hide resolved
aptos-move/framework/aptos-framework/sources/transaction_fee.move
Outdated
Show resolved
Hide resolved
aptos-move/framework/aptos-framework/sources/transaction_fee.move
Outdated
Show resolved
Hide resolved
aptos-move/framework/aptos-framework/sources/transaction_validation.move
Show resolved
Hide resolved
|
||
/// Stores the transaction fee collected to the specified validator address. | ||
public(friend) fun add_transaction_fee(validator_addr: address, fee: Coin<AptosCoin>) acquires ValidatorFees { | ||
let fees_table = &mut borrow_global_mut<ValidatorFees>(@aptos_framework).fees_table; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we add a safeguard here in case the ValidatorFees resource has not been initialized?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then we would have a coin which we cannot drop (assuming we guard with if !exists<..>(..) return
? Both CollectedFeesPerBlock
and ValidatorFees
are published at the same time, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm that's true that we can't drop or burn the coins here 🤔 It's fine not to have the safeguard then if those 2 resources are guaranteed to be published together. cc @junkil-park
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks good now. There are 3 followups I think we should do:
- Add e2e (move tests) or smoke tests for fee distribution.
- Add an initialization script that will be used as the first step in the multistep proposal that would first initialize the required resources and then enable the feature flag
- Some manual testing in local network + devnet
|
||
/// Creates a new aggregatable coin with value overflowing on `limit`. Note that this function can | ||
/// only be called by Aptos Framework (0x1) account for now becuase of `create_aggregator`. | ||
public(friend) fun initialize_aggregatable_coin<CoinType>(aptos_framework: &signer): AggregatableCoin<CoinType> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need these functions here or can this be done directly in transaction_fee (with added friendship between transaction_fee and aggregatable coin)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
initialize_aggregatable_coin
and is_aggregatable_coin_zero
can be moved to transaction_fee, but drain_aggregatable_coin
, merge_aggregatable_coin
and collect_from_into_aggregatable_coin
have to stay in coin module to allow calling Coin constructor/destructor.
aptos-move/framework/aptos-framework/sources/reconfiguration.move
Outdated
Show resolved
Hide resolved
1. Why we set proposer to option::none() 2. How cases when a validator is removed are handled.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
Enables transaction fees distribution. In particular, this adds: 1. API for processing transaction fees, see `transaction_fee.move` 2. API for aggregatable coin used to collect the fees, see `coin.move` 3. API for distributing fees, see `stake.move` Also, Move unit tests are added to simulate the block execution.
First PR to enable transaction fees distribution. In particular, it adds:
transaction_fee.move
coin.move
stake.move
Also, Move unit tests were added to simulate block execution.
Next PR: smoke and e2e tests, as this PR has quite a bit of changes already :)