-
Notifications
You must be signed in to change notification settings - Fork 374
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: add valset injection through r/sys/validators
#2229
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2229 +/- ##
==========================================
+ Coverage 54.88% 54.92% +0.03%
==========================================
Files 592 594 +2
Lines 79232 79297 +65
==========================================
+ Hits 43487 43550 +63
+ Misses 32460 32455 -5
- Partials 3285 3292 +7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
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.
Approving, but please follow the suggestions.
Co-authored-by: Manfred Touron <94029+moul@users.noreply.github.com>
Co-authored-by: Manfred Touron <94029+moul@users.noreply.github.com>
…gnolang/gno into dev/zivkovicmilos/val-injection
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.
I believe this approach is preferable 👍
You'll likely find this the most advanced use of avl
you've encountered so far.
My previous comments were merely suggestions on how to potentially maximize the utilization of avl
features. I hope you find this helpful.
## 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>
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:
ConsensusState
-> refactoring this is not a small feat, and saying this is an understatementThe way this flow essentially works is the following:
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)abci.ValidatorUpdates
, which are returned as a result ofEndBlocker
EndBlocker
result is later read by theConsensusState
, 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 #2130
Closes #1823
Related: #1945
Contributors' checklist...
BREAKING CHANGE: xxx
message was included in the description