Skip to content
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

feat(iota-framework): storage fund's ability earn staking rewards #959

Conversation

Dkwcs
Copy link
Contributor

@Dkwcs Dkwcs commented Jul 2, 2024

Description of change

Removed storage_fund_reinvest_rate and leftover_staking_rewards effect on storage_fund.
Storage fund doesn't earn from leftover or reinvest rewards.

Links to any relevant issues

fixes #937 .

Type of change

  • Enhancement (a non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

How the change has been tested

Run tests - kinesis/crates/iota-framework/packages/iota-system

@Dkwcs Dkwcs requested review from kodemartin, miker83z and a team as code owners July 2, 2024 17:55
@Dkwcs Dkwcs added the sc-platform Issues related to the Smart Contract Platform group. label Jul 2, 2024
@Dkwcs Dkwcs self-assigned this Jul 2, 2024
@Dkwcs Dkwcs changed the base branch from sc-platform/issue-153 to sc-platform/issue-946-retain-iota-treasury-cap July 3, 2024 08:20
Base automatically changed from sc-platform/issue-946-retain-iota-treasury-cap to sc-platform/issue-153 July 3, 2024 08:25
@@ -948,7 +935,6 @@ module iota_system::iota_system_state_inner {
reference_gas_price: self.reference_gas_price,
total_stake: new_total_stake,
storage_charge,
storage_fund_reinvestment: storage_fund_reinvestment_amount as u64,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to also be removed in iota_types::event::SystemEpochInfoEvent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll create a separate issue for that
Because of removing of storage_fund_reinvest_rate looks dangerous in some places.
We'll do it separately

storage_fund_reinvest_rate: u64, // share of storage fund's rewards that's reinvested
// into storage fund, in basis point.
reward_slashing_rate: u64, // how much rewards are slashed to punish a validator, in bps.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This param must also be removed in the call to advance_epoch in iota_adapter_latest::execution_engine::checked::construct_advance_epoch_pt (as well as v0, v1, v2).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll create a separate issue for that
Because of removing of storage_fund_reinvest_rate looks dangerous in some places.
We'll do it separately

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you think it is better to do this in a separate issue, please, add a subtask and implement it based on this branch.
I think we should not merge this branch without removing storage_fund_reinvest_rate from the Rust side because our main branch will be broken in this case.

Copy link
Contributor Author

@Dkwcs Dkwcs Jul 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Issue - #970

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should not merge this branch without removing storage_fund_reinvest_rate from the Rust side because our main branch will be broken in this case.

Exactly why I suggested these changes. Without this change and the SystemEpochInfoEvent update, the iota-test-validator does not work. The required changes are not huge, so we should do it in this branch, imo, otherwise we cannot merge this PR without breaking our issue 153 branch.

Issue 970 deals with multiple things now. I think we simply should do the appropriate changes to the Rust types in this PR, and left 970 deal only with the naming changes. There are lots of variables and fields that contain the storage_fund name and those should be updated to storage_deposit(s). So 970 should only be a renaming task, imho, not a logic change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I'll fix storage_fund_reinvest_rate in Rust code

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check it out please

…f github.com:iotaledger/kinesis into scl1/rid-storage-fund's-ability-earn-staking-rewards
@@ -931,12 +919,11 @@ module iota_system::iota_system_state_inner {
let mut leftover_staking_rewards = storage_fund_reward;
leftover_staking_rewards.join(computation_reward);
let leftover_storage_fund_inflow = leftover_staking_rewards.value();


self.iota_treasury_cap.supply_mut().decrease_supply(leftover_staking_rewards);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to clarify what to do with the leftovers and make a final implementation or add a TODO.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In progress

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line fails to compile now since IotaTreasuryCap must be used differently than TreasuryCap<IOTA>.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

Comment on lines 40 to 39
non_refundable_storage_fee_amount: u64,
//TODO: try the way to configure
_non_refundable_storage_fee_amount: u64,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should not be removed?

Copy link
Contributor Author

@Dkwcs Dkwcs Jul 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverted those changes.

Copy link

@PhilippGackstatter PhilippGackstatter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me now (after you deal with the IotaTreasuryCap changes). Move tests all pass, iota-test-validator compiles and runs and can successfully advance epochs 👍 .

@@ -890,11 +883,6 @@ module iota_system::iota_system_state_inner {

let storage_fund_reward_amount = storage_fund_balance as u128 * computation_charge_u128 / total_stake_u128;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Dkwcs This is the line where the storage fund is earning rewards, this and the following shall be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we have to completely remove the storage_fund_rewards from validators.advance_epoch or replace it with something?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In SUI the storage fund earns rewards itself from the stake susibidies, i.e. it is treated as stake. It goes back to the validators as additional reward.

In IOTA the storage deposit does not earn staking rewards, it is not considered staked. It doesn't generate rewards. So answering your question:

So we have to completely remove the storage_fund_rewards from validators.advance_epoch or replace it with something?

Yes, remove it completely.

@Dkwcs Dkwcs marked this pull request as draft July 4, 2024 15:01
@Dkwcs Dkwcs closed this Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sc-platform Issues related to the Smart Contract Platform group.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants