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

Parachain auctions #239

Merged
merged 46 commits into from May 25, 2019

Conversation

Projects
None yet
6 participants
@gavofyork
Copy link
Member

commented May 1, 2019

Closes #234

Still TODO:

  • Tests
  • Events
  • Docs

gavofyork added some commits May 1, 2019

@rphmeier

This comment has been minimized.

Copy link
Member

commented May 6, 2019

Inprogress?

gavofyork added some commits May 9, 2019

@shawntabrizi

This comment has been minimized.

Copy link
Member

commented May 21, 2019

which we don't want for a parachain. Overlapping bids are mutually exclusive.

I see, so we want all lease period indices for any one parachain to be continuous? This is a game theory thing, or a user experience thing?

@bjornwgnr

This comment has been minimized.

Copy link
Member

commented May 22, 2019

Because you might win with both bids. Which is bad if they have a gap say 1 and 3, which we don't want for a parachain.

Have you considered allowing the gap period to be auctioned again i.e. at a later time? I guess this would add too much complexity or introduce other issues and wouldn't be particularly good from a UX perspective

Show resolved Hide resolved runtime/src/slots.rs Outdated
Show resolved Hide resolved runtime/src/slots.rs Outdated
Show resolved Hide resolved runtime/src/slots.rs Outdated
Show resolved Hide resolved runtime/src/slots.rs Outdated
Show resolved Hide resolved runtime/src/slots.rs Outdated
@AlistairStewart

This comment has been minimized.

Copy link

commented May 22, 2019

Because you might win with both bids. Which is bad if they have a gap say 1 and 3, which we don't want for a parachain.

Have you considered allowing the gap period to be auctioned again i.e. at a later time? I guess this would add too much complexity or introduce other issues and wouldn't be particularly good from a UX perspective

That isn't the issue. The problem is if we win slots 1 and 3, then we'd start a parachain at slot 1, have to have it stop at slot 2 and then restart it or start another parachain at slot 3. This seems like a bad idea as we don't plan to pause parachains that don't manage to renew their lease. Instead the current plan for stopping parachains is to return all the DOTs they own to accounts they specify.

So we don't want the same bidder to win slots 1 and 3. That might mean that even if we had the highest bid on those slots, then the optimal set of winning bids might include our bid on 1 and say someone else's lower bid on slot 3. But unfortunately, we only store the highest bid on each interval, so we can't handle this situation.

We get round this by ignoring someone's bid on slot 3 if they have the highest bid on slot 1, as we might need to combine that with the current highest bid on slot 3.

That's why we have this limitation.

@gavofyork

This comment has been minimized.

Copy link
Member Author

commented May 24, 2019

I haven't looked too closely at the auction logic itself. My main question is about usability: is it possible to use e.g. a "sudo" key to register parachains without messing up the auction logic?

yes. the auctioning system is designed to only "maintain" ParaId values that it generated. any parachains registered outside of these values will just dispassionately "exist".

gavofyork and others added some commits May 24, 2019

Update runtime/src/slot_range.rs
Co-Authored-By: Robert Habermeier <rphmeier@gmail.com>
Update runtime/src/slots.rs
Co-Authored-By: Shawn Tabrizi <shawntabrizi@gmail.com>
Update runtime/src/slots.rs
Co-Authored-By: Shawn Tabrizi <shawntabrizi@gmail.com>
@gavofyork

This comment has been minimized.

Copy link
Member Author

commented May 24, 2019

@shawntabrizi grumbles addressed

@gavofyork

This comment has been minimized.

Copy link
Member Author

commented May 24, 2019

@Kianenigma waiting for you :)

@Kianenigma

This comment has been minimized.

Copy link

commented May 24, 2019

@Kianenigma waiting for you :)

forgot to mention: all the above comments are the combination of me and @shawntabrizi sitting down together and going through the code. You can discard me as a separate reviewer.

I was going through your answers and from the looks of it, most of the critical ones were our misunderstanding. We will probably sit down together in a few more sessions to learn more about it. Merging or waiting would be up to you IMO.

gavofyork added some commits May 24, 2019

@gavofyork gavofyork merged commit be79c5d into master May 25, 2019

1 check passed

ci/gitlab/239 Pipeline passed on GitLab
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.