feat(PoC,gov): initial sys/validators and gov/dao contracts #1945
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: moul <94029+moul@users.noreply.github.com>
github-actions
bot
added
the
🧾 package/realm
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1945 +/- ##
==========================================
+ Coverage 54.62% 57.34% +2.71%
==========================================
Files 581 419 -162
Lines 77954 66663 -11291
==========================================
- Hits 42583 38225 -4358
+ Misses 32193 25610 -6583
+ Partials 3178 2828 -350
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
moul
changed the title
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
moul
changed the title
moul
changed the title
moul
changed the title
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
|
Not finished yet. Seeking initial review, feedback, and questions to aid in continuation. |
moul
changed the title
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: moul <94029+moul@users.noreply.github.com>
Signed-off-by: gfanton <8671905+gfanton@users.noreply.github.com>
|
this broke master gnodev fails with: |
7 tasks
zivkovicmilos
pushed a commit
that referenced
this pull request
Jun 12, 2024
This PR addresses the issue of poor module naming introduced in the recent merge #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> Signed-off-by: gfanton <8671905+gfanton@users.noreply.github.com>
zivkovicmilos
pushed a commit
that referenced
this pull request
Jun 17, 2024
Continues #1945 --------- Signed-off-by: moul <94029+moul@users.noreply.github.com>
thehowl
added a commit
that referenced
this pull request
Jun 17, 2024
…d of the opposite (#2353) Please, can we take a bit of care when modifying the syntaxes of our makefile commands? They may not break code, but they break documentation and user flows. We can add a CI check as well; I see this for another PR as this is a hotfix. (Currently, running `make install` / `make install.gnodev` in the top-level directory doesn't work; because @moul inverted these in #1945). This is still not a substitute for a bit of good ol' attention in recognising when something is user-facing and thus should be changed with a bit more care and reason. Note, I'm NOT saying that we should not change things, as we are before any 1.0 so we should change anything that makes sense; but it is a good practice that when changing a flag, command, etc., to do a global search for the old syntax to see examples where old documentation or untested code is broken.
7 tasks
moul
added a commit
that referenced
this pull request
Jul 2, 2024
## Description This PR introduces an initial validator set implementation in Gno (realm based), as outlined in #1824. It introduces a Proof of Contribution validator set management mechanism, based on govdao proposals. Related PRs: - #1945 - #2344 I've left the door open to arbitrary protocol implementations. ~I've also added 2 example implementations:~ - ~PoS (Proof of Stake) - users can stake funds (`ugnot`) to become part of the on-chain validator set~ - ~PoA (Proof of Authority) - new validators need to be voted in by the majority of the existing validator set~ Update: I've moved the example PoS + PoA implementation to another unrelated PR, since they are out of scope Closes #1824 <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] 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>
zivkovicmilos
added a commit
that referenced
this pull request
Jul 7, 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 #2130 Closes #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: #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>
gfanton
pushed a commit
to gfanton/gno
that referenced
this pull request
Jul 23, 2024
## Description This PR introduces an initial validator set implementation in Gno (realm based), as outlined in gnolang#1824. It introduces a Proof of Contribution validator set management mechanism, based on govdao proposals. Related PRs: - gnolang#1945 - gnolang#2344 I've left the door open to arbitrary protocol implementations. ~I've also added 2 example implementations:~ - ~PoS (Proof of Stake) - users can stake funds (`ugnot`) to become part of the on-chain validator set~ - ~PoA (Proof of Authority) - new validators need to be voted in by the majority of the existing validator set~ Update: I've moved the example PoS + PoA implementation to another unrelated PR, since they are out of scope Closes gnolang#1824 <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] 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>
gfanton
pushed a commit
to gfanton/gno
that referenced
this pull request
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR showcases a model that combines multiple contracts with defined goals and constraints. The aim is to make everything in
sys/*usable by the chain (tm2 powered) efficiently, with minimal need for updates while maintaining flexibility in usage.The
sys/contracts focus on defining data types and helpers to ensure that received callbacks meet minimal constraints, like GovDAO approval. They do not handle DAO logic or state due to complexity and upgradability requirements for DAOs.I won't include complete DAO examples in this PR. Imagine having these sections once everything is done:
{p,r}/sys: minimal interface with the chain{p,r}/gov: simple DAO frameworks{p,r}/*: where users will develop permissionless logic and propose it togovfor approval usingsysto trigger the chain.Personal note -> try to introduce and document the notion of "pausable threads". Related with #1974.
TODO:
depends on std.Emit (#575).
depends on #1948 (need rebase).