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

Genesis validators must have registered peer ids at genesis #960

Closed
AlastairHolmes opened this issue Dec 8, 2021 · 8 comments
Closed

Genesis validators must have registered peer ids at genesis #960

AlastairHolmes opened this issue Dec 8, 2021 · 8 comments
Assignees
Labels
discussion Discussions about proposed changes or ideas State Chain

Comments

@AlastairHolmes
Copy link
Contributor

A genesis nodes are validators therefore they must have on-chain registered peer ids. If a ceremony was started with the genesis validators, but they haven't registered their peer ids the ceremony would fail.

So the genesis block should include a peer id mapping for the genesis validators.

@morelazers
Copy link

I don't think we're too worried about this.

The Genesis Validators are already staked by design, so they have enough FLIP to submit an extrinsic.

As soon as the CFE comes online, we submit an extrinsic to register the Peer Id (as far as I know, maybe it actually works differently, if so please explain).

We can't start and succeed a ceremony without the CFE (and I guess can't... fail one either? We'll just keep retrying until enough CFEs come online).

Maybe I'm missing something, but by my reckoning by the time we get to a chain's first ceremony, if we don't already have the genesis peer ids on chain, something has gone seriously wrong.

@morelazers morelazers added the discussion Discussions about proposed changes or ideas label Dec 8, 2021
@andyjsbell
Copy link

I suppose the advantage of being in the genesis block is that we make no assumptions and have an expected state from the off.

@morelazers
Copy link

But that would require their IP addresses to be hardcoded into the chainspec, right? It just seems pretty ugly for no material benefit.

@andyjsbell
Copy link

But that would require their IP addresses to be hardcoded into the chainspec, right? It just seems pretty ugly for no material benefit.

Good point. It sounded nice until reality hit 👍

@AlastairHolmes
Copy link
Contributor Author

But that would require their IP addresses to be hardcoded into the chainspec, right? It just seems pretty ugly for no material benefit.

Not at the moment, only peer id's public key.

@morelazers
Copy link

@AlastairHolmes I thought we agreed in a design discussion at the start of this exercise that we would store the IP addresses on-chain. I believe this is what we discussed with @dandanlen present. All parties were happy.

This is one of the reasons that we should have a formal plan for our solutions (as per the Branch Planning document), because now the spec has changed and I am unaware of it.

I don't want to derail this issue, but I would like an answer to this question: Why are we not storing IP addresses on-chain?

@AlastairHolmes
Copy link
Contributor Author

AlastairHolmes commented Dec 13, 2021

As I mentioned to you last week, as there is difficulty in deciding what IP Address to store, I never intended to not go the route of storing the IPs in the end, but we did need a working solution ASAP.

@morelazers
Copy link

Going to close this since I don't think that it's an issue. Happy to reopen if there are any disagreements.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussions about proposed changes or ideas State Chain
Projects
None yet
Development

No branches or pull requests

3 participants