polkadot icon indicating copy to clipboard operation
polkadot copied to clipboard

Update polkadot inflation to take into account auctions

Open kianenigma opened this issue 2 years ago • 1 comments

fixes https://github.com/paritytech/polkadot/issues/5195 We should probably also close #3011 as we move to Polkadot, as the current approach is kind of a guess, without taking into account the number of slots that where actually auctioned.

Not exactly sure if this makes sense, as it was added mixed with the guilts PR (https://github.com/paritytech/polkadot/pull/2587), which polkadot does not have.

Also related: https://github.com/paritytech/substrate/issues/8327

kianenigma avatar Aug 11 '22 08:08 kianenigma

Looks ok - we might eventually want the economics of Polkadot to diverge from Kusama and thus need greater parameterisation with the common era_payout function. But it's probably fine for now.

gavofyork avatar Sep 14 '22 13:09 gavofyork

@kianenigma you want to move forward with this?

bkchr avatar Oct 07 '22 07:10 bkchr

@kianenigma you want to move forward with this?

Yes, I made one attempt with my current commits that more or less works, but it needs a shitty data seeding. After chatting a bit with @KiChjang about it, we concluded that it can probably be done better. But I can't yet find the correct storage items that I need onchain, if they exist.

In short, we want a list of "active para ids that are there through an auction".

@shawntabrizi is probably a better person to guide me here, but I will nonetheless continue.

The staking rate in Polkadot and Kusama is not off because of this.

kianenigma avatar Oct 08 '22 08:10 kianenigma

I don't see this as the right immediate answer. The first thing I would do is create a new storage in the slots pallet to keep track of all the parachains which are active in a lease period.

From that, we will know how many parachains we have each lease period has. That seems like a better number to start with than what you have done here, which is not clear to me is even right, since this list never has items removed when they are offboarded.

shawntabrizi avatar Oct 08 '22 22:10 shawntabrizi

That seems like a better number to start with than what you have done here, which is not clear to me is even right, since this list never has items removed when they are offboarded.

The new list is never cleared, and it is supposed to represent the para-id of all parachains that have been offboarded. Then, we take the intersection of this with the current list of active para-ids, and that's the right number.

I actually think this is "correct", but perhaps what you are suggesting is easier.

kianenigma avatar Oct 09 '22 09:10 kianenigma

So if a parachain is auctioned, then offboards, then becomes a common good chain...

And does this handle the same parachain winning 2 auctions? AFAIK it duplicates data then?

Not convinced this is really right

shawntabrizi avatar Oct 09 '22 19:10 shawntabrizi

So if a parachain is auctioned, then offboards, then becomes a common good chain...

Good point, this is not handled. A common good para is no longer locking any DOT and should not be tracked.

And does this handle the same parachain winning 2 auctions? AFAIK it duplicates data then?

The data in the new storage item is duplicate, but it will easily be deduplicated by making sure in the final filter, we do active_para_ids.filter(|i| auction_winners_with_dupe.contains(i)) so even if a para-id has won multiple auctions, it is taken into account.


I will revise my approach nonetheless.

kianenigma avatar Oct 10 '22 06:10 kianenigma

So as I mentioned on Element, it would seem to me that the quick and easy way to do this is simply by doing active_para_ids.filter(|i| i >= LOWEST_PUBLIC_ID), as we know for certain that ParaIds that are >= 2000 are done through auctions, hence there's no need to look into the auction_winners_para_ids storage item.

KiChjang avatar Oct 13 '22 10:10 KiChjang

merging speculatively to meet deadlines, def. need to wait for audit before enactment.

kianenigma avatar Nov 08 '22 08:11 kianenigma

bot merge

kianenigma avatar Nov 08 '22 08:11 kianenigma

Ran some experiments on Polkadot, numbers add up. As expected, rewards will be more:

[runtime/polkadot/src/lib.rs:2442] DOT::from(total_issuance) = 1254311394,594 DOT (12,543,113,945,943,955,614)
[runtime/polkadot/src/lib.rs:2443] DOT::from(total_staked) = 614859453,927 DOT (6,148,594,539,274,007,157)

// in this PR
[runtime/polkadot/src/lib.rs:2446] DOT::from(validators) = 301672,607 DOT (3,016,726,077,584,039)
[runtime/polkadot/src/lib.rs:2447] DOT::from(remainder) = 41739,136 DOT (417,391,361,414,989)

// before this PR
[runtime/polkadot/src/lib.rs:2450] DOT::from(validators) = 254192,206 DOT (2,541,922,068,857,701)
[runtime/polkadot/src/lib.rs:2451] DOT::from(remainder) = 89219,438 DOT (892,194,382,832,565)

kianenigma avatar Nov 25 '22 00:11 kianenigma

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/change-in-stake-rewards-rate-2023-jan-13-and-14/2387/2

Polkadot-Forum avatar Mar 22 '23 09:03 Polkadot-Forum