-
Notifications
You must be signed in to change notification settings - Fork 36
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
feat: adds orchestrator address to validator in staking module #112
feat: adds orchestrator address to validator in staking module #112
Conversation
Adds to: celestiaorg/celestia-app#283 |
…ress_to_validator_init
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we merge this PR to that branch ?
Fixing the rest of the tests + adding new ones + adding checks would result in a really huge PR.
I would prefer to keep it incremental.
Let's merge this even if the CI is not passing to have easier reviews afterwards.
@evan-forbes Can you take a look please ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this makes sense I think, and I'm find with approving even with failed CI as long as its not the default branch.
We also need to start thinking about the scenario where we don't start from genesis, and instead we hardfork/upgrade to include the QGB, and what state migrations would be required.
Some thoughts around starting the QGB. Messaging compatibilityIn the scenario where we don't start from genesis, I guess it is still alright. Around starting the QGB on an existing chainFor an already running chain, to start the QGB, we only need the current valset to have orchestrator/Ethereum addresses. There can be two ways to do it. Hard fork the chainAdd a new parameter specifying the height we want to start the QGB on. When we start the QGB, any validator who doesn't have an Ethereum/orchestrator address setup, they get kicked from the valset (we could add some validator set sanitization mechanism). Social coordinationAsk the validators to update their software and set up the Orchestrator/Ethereum address gently. Then, we start the QGB once all the current valset validators are ready (we give them a week or so, to be ready). After starting the QGBPost the starting ceremony, we could have a new check on the staking module, verifying that no validator can move to the current validator set if it doesn't have an orchestrator/Ethereum address set. Questions
|
@evan-forbes Does it make sense to create some issue where we discuss this ? |
let's discuss synchronously, and then create issues there's a specific way to migrate state during a hardfork/upgrade using the sdk, and we will want to use that |
Sounds good 👍 I will merge this PR now. |
@evan-forbes I don't have permissions to merge :( Can you please? |
) | ||
|
||
// EthAddress Regular EthAddress | ||
type EthAddress struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be changed with Geth implementation
…tiaorg#112) * adds orchestrator address to validator initialization in staking module * fix msg edit validator * todo * todo
…tiaorg#112) * adds orchestrator address to validator initialization in staking module * fix msg edit validator * todo * todo
…tiaorg#112) * adds orchestrator address to validator initialization in staking module * fix msg edit validator * todo * todo
adds orchestrator address to validator in staking module