-
Notifications
You must be signed in to change notification settings - Fork 16
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
Comments
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. |
I suppose the advantage of being in the genesis block is that we make no assumptions and have an expected state from the off. |
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 👍 |
Not at the moment, only peer id's public key. |
@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? |
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. |
Going to close this since I don't think that it's an issue. Happy to reopen if there are any disagreements. |
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.
The text was updated successfully, but these errors were encountered: