search

paritytech / polkadot-sdk

The Parity Polkadot Blockchain SDK
https://polkadot.com/
1.91k stars 704 forks source link

Parachain Slot Extension Story #877

Open shawntabrizi opened 2 years ago

shawntabrizi commented 2 years ago

As the first set of parachains are going to end their lease period, we need to make sure there is a well designed story around extending the lease period of existing parachains such that there is no downtime.

There are a bunch of different ideas an approaches to this story, so lets list them all below.

Extending a Crowdloan with Another Crowdloan

All teams that have won a parachain slot so far has done so via crowdloans.

The intention of crowdloans is to be a one-off bootstrapping mechanism, not a permanent repeatable process.

To run a second crowdloan is also a bit dubious since the main incentive for users to participate in a crowdloan is to get tokens from the parachain. Usually a significant amount of the token supply is reserved for this, like 20 - 30%. In the case of a second crowdloan, will chains just mint another 20% more tokens?

That being said, some teams have declared interest in this, and specifically allowing crowdloan contributors access to their previously contributed funds so they can use it in a second crowdloan, without having any parachain downtime.

The current idea is to release the funds of crowdloan contributors a few weeks ahead of the end of a parachain slot, and thus the users can use those funds for whatever they see fit.

To enable this, we must write some new logic related to when a crowdloan can be dissolved, specifically allowing it to happen even though a parachain will have a slot won by a crowdloan.

Concerns

None as of yet.

Allowing a Parachain to Bid on an Overlapping Lease Period

Teams have also been interested in directly bidding for a new slot by winning a full set of lease periods that may overlap a lease period already won by that parachain.

At the moment we have this check which prevents this:

// We also make sure that the bid is not for any existing leases the para already has.
ensure!(
    !T::Leaser::already_leased(para, first_slot, last_slot),
    Error::<T>::AlreadyLeasedOut
);

Concerns

The reason we did not allow this was specifically to prevent griefing by a whale parachain from winning auctions from other people. Even in the Slots pallet, we check for this, and bail from giving the parachain any slots at all:

// The chain tried to lease the same period twice. This might be a griefing
// attempt.
//
// We bail, not giving any lease and leave it for governance to sort out.
return Err(LeaseError::AlreadyLeased)

This is a concern specifically because we allow a parachain to bid with funds already used in a previous bidding process, exactly for preventing parachain downtime. So if we removed this check, a parachain could win slots 1 - 8, then for every auction for the rest of Polkadot, this parachain could bid in that auction with all of those same funds, basically making it so that only one parachain is onbarded onto Polkadot.

So without much deeper refactoring, this does not seem like a viable solution.

Allowing Lease Period and Deposit Swaps

Investigating

Update Auction Winner Calculation Logic

Currently, the auction winner calculation logic is not well suited to support parachains with existing lease periods to win additional lease periods. Imagine the following example:

Currently the winner of this auction would be Parachain A because the calculation logic would add the deposit price of each lease period together.

However, technically more DOT is being locked in the situation with Parachain B and C because the 1000 DOT locked for lease period 5 - 8 would be locked for 1 - 4 too, even if it is "not being used", since we must make sure to keep the funds from the user so that they dont spend the funds later and cause issues where they don't have enough DOT to onboard.

One solution would be to allow chains with an existing lease period to get credit for already having a lease period, and having that count toward the calculated price.

An even easier more general solution may be to just weight each bid by the slot period depth. So the previous situation will become:

An

In progress...

joepetrowski commented 2 years ago

Extending a Crowdloan with Another Crowdloan

One problem with the solution of releasing tokens a few weeks before lease expiry is the current pattern of auctions for LP+1, where LP is the current lease period, each lasting 6 weeks on Kusama. Even if we release a few weeks ahead of time, there could still be a several-week period of downtime for a parachain.

The networks could run shorter auctions for alternating starts: i.e. some starting in LP and other in LP+1, so bidders could decide if they want to onboard immediately (losing the already passed blocks of LP, presumably for continuity) or onboard in the future to use the entire lease.

Allowing a Parachain to Bid on an Overlapping Lease Period

I realized later that a team doesn't need to bid for the entire 8 LPs of an auction :facepalm: . We can leave the ensure check in place and teams can only bid on the LPs that would extend their current lease. However, this is a bit weak economically as a bidder who bids on e.g. only the last LP of an auction has their bid locked up for all LPs of the auction, but their bid is scored based only on what they bid for. I'm not sure what the best solution is, as it would be fair to weight bids based on how long the bid would be locked, not on how many LPs it is for, but that's not great for the system as it leaves unused LPs from the auction if nobody bids on them.

xlc commented 2 years ago

Another issue I would like to point out is that the same batch of parachains are going to end their lease at same time. So there needs to be an economically friendly way for all of those parachains to have reasonably good chance to renew their slots.

Especially the current case there are 4 scheduled auction for least 21 and 5 parachains ending their lease at 20. The supply & demand is just bad. Even we got one more for auction for lease 21, that still means all 5 of those parachains are likely need to overpay the lease. No one wants to be the one that have to join an auction that they must win or out of business for 6 weeks.

AlistairStewart commented 2 years ago

We need to consider the goals first before evaulating possible solutions. But first, history.

The design is the way it is because we hoped that parachains would be bidding at least to extend their lease with their own tokens. We also hoped that they would be continously bidding on the last period to extend their leases. The idea here was to encourage continuity - we don't want a parachain with a lot of value to suddenly lose 1 auction to a random newcomer and be demoted to a parathread for a bit.

Of course this hasn't happened on Kusama as yet. One issue is that we can only reuse DOTs locked for auctions in the code now if the parachain itself bids via UMP.

The crowdloan pallet on the relay chain was deliberately simple. We hoped that more complex logic would be possible on a parachain. That hasn't happened yet either, despite the Defi chains looking at crowdloan derivatives. Putting crowdloan logic on a leased parachain is also a risk, especially without parathreads working yet, because that chain might not be a parachain when the lease ends. Because chains are not extending their leases period by period, we really don't have good guarantees that using them for crowdloan logic is sensible. We could always look at common good parachains for this purpose, but it might be better to let existing teams solve it.

None of the proposed solutions help with continuity and parachains extending their lease period by period.

Crowdloans releasing funds early helps with extending leases with new crowdloans - but they have to do it in the last period, which we don't want to encourage. Because we might have an existing valuable chain knocked out by a single newcomer in the last auction. If we had parachains extending their lease period by period, they have many more auctions to extend their slot - making this much less likely.

If we do release crowdloans early then we should also release all auction bids early. One benefit of this is that I can run a crowdloan on a parachain to extend that parachain, and even if it later fails to extend its lease, crowdloaners should always be able to get their tokens back while it is a parachain before it is demoted to a parathread.

Update Auction Winner Calculation Logic

The problem with this solution is that it encourages us to split the leases and benefits new DOTs being locked and not reusing existing locked DOTs. This really benefits new entrants makes it less likely we have parachains that stay around for years.

Allowing a Parachain to Bid on an Overlapping Lease Period

This is just a terrible idea but I have an alternative winner calculation logic that is not as radical as yours but still is at least as good as an overlapping bid. The proposal achieves the following property:

If a bid does not have any equal or higher bids whose range intersects with it then it is guaranteed to be in the winning set.

So to look at modifications of your example:

For this example C and B win, but

In this example A wins. The idea is the contribution of a period to the score is the maximum of the bids locked during that period ( in the current rule, it is the winner for that period. In your rule, it would be sum rather than max of bids winning on this and future periods). But you need a tie-breaker for that. So I'll write up this sometime in a HackMD where I can explain it better than a github comment.

I'm not sure whether any such change deals with our current issue. We really face a choice of doing something less perfect, implementing a short term solution that we communicate will not be continued, or just hoping that parachain bidding logic can be deployed in time. I suppose we could write or get someone to write a pallet for parachains that does what we think they should do if they could get the tokens.

amitrovich commented 2 years ago

Thanks for looking into this, guys! Very much looking forward to the solution. Our main need is to be able to use our KSM/DOTs for extending the lease, otherwise the amounts of reserves we need are double. I'm pretty sure most parachains use a similar approach (using the mix of their own KSM/DOTs and community support) and have the same need.

jonasW3F commented 2 years ago

The intention of crowdloans is to be a one-off bootstrapping mechanism, not a permanent repeatable process.

To run a second crowdloan is also a bit dubious since the main incentive for users to participate in a crowdloan is to get tokens from the parachain. Usually a significant amount of the token supply is reserved for this, like 20 - 30%. In the case of a second crowdloan, will chains just mint another 20% more tokens?

During the interviews that I conducted with several parachain teams, they strongly expressed a desire to further utilize crowdloans in the future (results are part of the first auction report, where I take a closer look on the situation where teams need to extend leases).

Most if not all projects are having their own treasuries which would allow them to continuously offer tokens to their crowdloan contributors. Also, some projects might reserve some of their initial supply for a future crowdloans and/or offer rewards on another chain (e.g., on Polkadot/Kusama). Since those things should be entirely managed by the respective parachains, we should allow flexbility. That being said, with more functionalities in the network, I can see projects creating their own versions of trustless crowdloans (especially those that separate bidding from gathering funds). If this does not involve major refactoring of the code, we should make it possible to use crowdloans again.

The current idea is to release the funds of crowdloan contributors a few weeks ahead of the end of a parachain slot, and thus the users can use those funds for whatever they see fit.

I share Al's concern that this would incentivize counting on the last moments to extend a slot. However, in addition to other refinements, this shouldn't be a problem and be one strategy of many. So, I generally have no reservation of doing this. That being said, I think any change that we do here should only affect future crowdloans, because we should keep changes to rules retrospectively at a minimum. The situation was quite clear for all crowdloans and auctions and everything unfolded under those assumptions.

wischli commented 2 years ago

First of all, thank you @shawntabrizi for pushing this issue and providing a first working solution for the problem by allowing two parachain IDs to be swapped on Kusama. We hope this will rather be regarded as a temporary hotfix than a longterm solution.

During the interviews that I conducted with several parachain teams, they strongly expressed a desire to further utilize crowdloans in the future (results are part of the first auction report, where I take a closer look on the situation where teams need to extend leases).

@jonasW3F Could you put a quote in here? I couldn't find the result of the interview in that blog post.

Most if not all projects are having their own treasuries which would allow them to continuously offer tokens to their crowdloan contributors. Also, some projects might reserve some of their initial supply for a future crowdloans and/or offer rewards on another chain (e.g., on Polkadot/Kusama). Since those things should be entirely managed by the respective parachains, we should allow flexbility.

In the long term, we envision a mechanism which allows a parachain to directly bid or contribute to a crowdloan, ideally from their Treasury via XCM. This way, a parachain could use their Treasury funds to accumulate a supply of relay tokens for financing ongoing leases on their own.

jonasW3F commented 2 years ago

Hi @wischli Those were non-structured interviews that I didn't formalize into some write-up but rather informed the whole blog post (especially the section about the future). I hope that answers your question.

xlc commented 1 year ago

I guess this could be closed with agile core time?

SBalaguer commented 1 year ago

Indeed @xlc, that's something we discussed as well. However from recent discussions we will most probably propose to the community having another 2 LPs with auctions on Polkadot, which means around 6 months.

If #1749 can provide a quick and good solution that we can deploy in the next month or so, then I believe it still makes sense.

Ank4n commented 1 year ago

I would like to get more eyeballs and feedback on https://github.com/paritytech/polkadot-sdk/pull/1749 if they feel this is a good solution until we have the agile core time. Especially if we go ahead with it, how early should we allow the lease deposit to be refunded? @jonasW3F @AlistairStewart @shawntabrizi