[multinode] Validator set injection through a Realm #1823
Assignees
Labels
Milestone
Comments
zivkovicmilos
added
📦 🌐 tendermint v2
|
@zivkovicmilos are you working on it? please call me so we can clarify some details. |
|
@moul I'll ping you about this so we can set up a slot |
7 tasks
gfanton
pushed a commit
to gfanton/gno
that referenced
this issue
Jul 23, 2024
## Description This PR introduces an `EndBlocker` system for applying validator set changes protocol level, based on on-chain events (from the `/r/sys/vals` realm). I've utilized an already existing system: - validator set changes still stay managed protocol-level in `ConsensusState` -> refactoring this is not a small feat, and saying this is an understatement - event switch utilized by the node that dumps new block / new transaction events The way this flow essentially works is the following: 1. An on-chain event happens that indicates a change in the validator set (added / removed) 2. These events (ABCI events) are parsed as soon as they end up in a transaction result (are pushed to the event system of the SDK). The top-level ABCI event type needs to be`EventTx` (indicating it's a new TX result). The underlying tx GnoVM events (`GnoEvent`) need to be from the `/r/sys/validators` Realm, and be a validator addition / removal (type defined in the Realm) 4. Events are parsed down into `abci.ValidatorUpdates`, which are returned as a result of `EndBlocker` 5. This `EndBlocker` result is later read by the `ConsensusState`, and the validator set changes are applied for the upcoming block in a series of existing callbacks. This also keeps proposer priority logic in check. Blocked by gnolang#2130 Closes gnolang#1823 ```mermaid --- title: on-chain validator set injection flow --- flowchart TD subgraph app.go nesvw(["Node event switch"]) -. pass all block events .-> collector(["event collector"]) collector -. subscribes to .-> nesvw collector -. filter new events .-> collector EB["func EndBlocker(...)"] == 1: fetch relevant events ==> collector collector -. 2: return events, if any .-> EB end subgraph gno.land/r/sys/validators.gno GC["func GetChanges(from int64) []validators.Validator"] addVal["func addValidator(...)"] removeVal["func removeValidator(...)"] PE["func NewPropExecutor(changesFn) proposal.Executor"] PE -. calls internally .-> addVal PE -. calls internally .-> removeVal addVal -. std emits ValidatorAdded .-> nesvw removeVal -. std emits ValidatorRemoved .-> nesvw end subgraph gno.land/r/gov/dao.gno EP["func ExecuteProposal(...)"] EP == executes on-chain ==>PE end subgraph user_proposal.gno main("func main() {...}") PR["govdao.Propose(...)"] main -. contains .-> CB main -. contains .-> PR CB("changesFn func() []validators.Validator {...}") CB== creates ==>PE CB("changesFn func() []validators.Validator {...}") PE == passed into ==> PR end A[/fa:fa-user User\] == gnokey maketx run ==> main GDV[/fa:fa-people-group GOVDAO members\] == manually call ==> EP EB == 3: execute VM call to get changes since last block ==> GC GC -. 4: return changes .-> EB EB -. 5: return response with valset changes .-> EBR([abci.ResponseEndBlock]) -- applied in --> AB subgraph Cosmos SDK AB["func ApplyBlock(...) {...}"] end ``` Related: gnolang#1945 <details><summary>Contributors' checklist...</summary> - [ ] Added new tests, or not needed, or not feasible - [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [ ] Updated the official documentation or not needed - [ ] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details> --------- Co-authored-by: Manfred Touron <94029+moul@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
This effort covers the ability for the TM2 consensus mechanism to use the validator set that is specified in a Realm.
Currently, the validator set is kept in-memory (and on-disk), and changes to it are subject to protocol-level changes for mechanisms like PoS. This effort would tackle enabling the consensus layer to utilize a validator set that is abstracted away inside a Realm.
The benefit of having the validator set inside a Realm is the ability to transparently manage it and govern who can be validating and building blocks.
Successful outcome of this effort:
The text was updated successfully, but these errors were encountered: