Skip to content
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 server implementation of Group module #10570

Merged
merged 70 commits into from
Dec 10, 2021

Conversation

likhita-809
Copy link
Contributor

@likhita-809 likhita-809 commented Nov 18, 2021

Description

Closes: #9897
Closes: #9905

Adds server implementation of Group module and wires it up in simapp


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

@likhita-809 likhita-809 changed the title Add server implementation of Group module feat: Add server implementation of Group module Nov 18, 2021
types/module/server/derived_module_key.go Outdated Show resolved Hide resolved
types/module/server/id.go Outdated Show resolved Hide resolved
types/module/server/manager.go Outdated Show resolved Hide resolved
types/module/server/module.go Outdated Show resolved Hide resolved
types/module/server/module_key.go Outdated Show resolved Hide resolved
types/module/server/router.go Outdated Show resolved Hide resolved
types/module/server/testutil.go Outdated Show resolved Hide resolved
x/group/errors/orm.go Outdated Show resolved Hide resolved
x/group/keeper/keeper_test.go Outdated Show resolved Hide resolved
x/group/keeper/proposal_executor.go Outdated Show resolved Hide resolved
@codecov
Copy link

codecov bot commented Nov 23, 2021

Codecov Report

Merging #10570 (81dd664) into master (cf6ace5) will increase coverage by 0.37%.
The diff coverage is 67.32%.

❗ Current head 81dd664 differs from pull request most recent head f03ac5a. Consider uploading reports for the commit f03ac5a to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##           master   #10570      +/-   ##
==========================================
+ Coverage   65.03%   65.40%   +0.37%     
==========================================
  Files         612      634      +22     
  Lines       57798    60651    +2853     
==========================================
+ Hits        37590    39670    +2080     
- Misses      18101    18681     +580     
- Partials     2107     2300     +193     
Impacted Files Coverage Δ
baseapp/baseapp.go 66.96% <ø> (-0.15%) ⬇️
client/flags/flags.go 20.33% <0.00%> (-1.48%) ⬇️
client/query.go 30.58% <0.00%> (-0.74%) ⬇️
client/tx/factory.go 25.36% <0.00%> (-2.01%) ⬇️
types/tx/msgs.go 0.00% <ø> (ø)
types/tx/types.go 0.00% <0.00%> (ø)
x/auth/client/cli/tips.go 0.00% <0.00%> (ø)
x/auth/client/cli/tx_multisign.go 0.00% <0.00%> (ø)
x/auth/client/cli/validate_sigs.go 0.00% <0.00%> (ø)
x/auth/tx/builder.go 80.98% <ø> (ø)
... and 65 more

Copy link
Contributor

@amaury1093 amaury1093 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, I looked more closely into these parts:

  • Exec() server impl
  • proto defs

@blushi
Copy link
Contributor

blushi commented Dec 7, 2021

@anilcse @robert-zaremba @aaronc As approvers of the corresponding PR on regen-ledger: regen-network/regen-ledger#154, I'm requesting your reviews here in particular to try to make the review process faster for the group module migration to cosmos-sdk.

Here are some important changes that have been made since the original PR though:

  • use MsgServiceRouter instead of LegacyRouter for executing proposal msgs
  • use ADR 028 for group account address
  • use AppModuleBasic and AppModule for module definition (instead of our custom Modules on regen-ledger)

up @anilcse @robert-zaremba @aaronc could you have a look so we can move forward with this PR please? It's blocking some follow-up group module PRs. Thanks.

x/group/keeper/msg_server.go Outdated Show resolved Hide resolved
x/group/keeper/msg_server.go Outdated Show resolved Hide resolved
}

accountDerivationKey = buf.Bytes()
accountAddr = address.Module(group.ModuleName, accountDerivationKey)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are we 100% sure we won't have any other account type in the group module? If there will be other one (eg other type of groups, or some helper accounts), then we should use derivation:

parentAcc := address.Module(group.ModuleName, groupTablePrefix)
groupAddr := address.Derive(parentAcc, bytes_id)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I was hesitating on that but I think it's probably safest to use derivation indeed.
But I don't get why we would use groupTablePrefix here, maybe groupAccountTablePrefix would be more appropriate in this particular case of group account address creation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@robert-zaremba it's now using derivation, lmk what you think

}

acc := k.accKeeper.NewAccount(ctx, &authtypes.ModuleAccount{
BaseAccount: &authtypes.BaseAccount{
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need a BaseAccount for groups?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what would we use instead? It's a ModuleAccount btw, not just a BaseAccount

@robert-zaremba
Copy link
Collaborator

After thinking more about the addessables and ids, I think that each group should be identified by an address, not id uint64.
The ID is not needed, we can only keep the internal counter to generate new addresses. The we can use that address to compose the group directly with anything, without doing an additional index nor having a need for GroupInfo. Also it will normalize queries: We can use address everywhere and think about it as an account, without having an associated BaseAccount.

Copy link
Collaborator

@anilcse anilcse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, I agree with @robert-zaremba on replacing group-ids

@blushi
Copy link
Contributor

blushi commented Dec 9, 2021

lgtm, I agree with @robert-zaremba on replacing group-ids

A group is just an aggregation of accounts with associated weights, it doesn't have any decision or execution power without a decision policy, while a group with a decision policy = a group account does and has an address.
You can double check the docs: https://docs.regen.network/modules/group/01_concepts.html#group that outlines the current design:

Group accounts are abstracted from groups because a single group may have multiple decision policies for different types of actions. Managing group membership separately from decision policies results in the least overhead and keeps membership consistent across different policies.

@blushi blushi dismissed their stale review December 9, 2021 08:44

I partially worked on this PR so I can't really review it

@blushi
Copy link
Contributor

blushi commented Dec 10, 2021

@robert-zaremba I'll put automerge on so we can move forward with this and unblock the rest of the group PRs. Please create a separate issue if there's anything that you'd like to be addressed in a follow-up PR.

@blushi blushi added A:automerge Automatically merge PR once all prerequisites pass. and removed C:Simulations C:x/feegrant labels Dec 10, 2021
@mergify mergify bot merged commit 3495691 into master Dec 10, 2021
@mergify mergify bot deleted the likhita/group-server-implementation branch December 10, 2021 11:02
@faddat
Copy link
Contributor

faddat commented Dec 12, 2021

If we look at the go.sum file here, this brings the trouble that left us in v0.44.5 back in.

cosmos/gaia#1099

@faddat faddat mentioned this pull request Dec 12, 2021
@faddat
Copy link
Contributor

faddat commented Dec 12, 2021

I might have been reacting to nothing?

Or maybe not?

https://go.dev/ref/mod#minimal-version-selection

via @marbar3778

larry0x pushed a commit to larry0x/cosmos-sdk that referenced this pull request May 22, 2023
<!--
The default pull request template is for types feat, fix, or refactor.
For other templates, add one of the following parameters to the url:
- template=docs.md
- template=other.md
-->

## Description

Closes: cosmos#9897
Closes: cosmos#9905

Adds server implementation of Group module and wires it up in simapp

---

### Author Checklist

*All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.*

I have...

- [x] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] added `!` to the type prefix if API or client breaking change
- [x] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting))
- [x] provided a link to the relevant issue or specification
- [x] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules)
- [x] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing)
- [ ] added a changelog entry to `CHANGELOG.md`
- [x] included comments for [documenting Go code](https://blog.golang.org/godoc)
- [ ] updated the relevant documentation or specification
- [x] reviewed "Files changed" and left comments if necessary
- [ ] confirmed all CI checks have passed

### Reviewers Checklist

*All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.*

I have...

- [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title
- [ ] confirmed `!` in the type prefix if API or client breaking change
- [ ] confirmed all author checklist items have been addressed 
- [ ] reviewed state machine logic
- [ ] reviewed API design and naming
- [ ] reviewed documentation is accurate
- [ ] reviewed tests and test coverage
- [ ] manually tested (if applicable)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass. C:x/feegrant C:x/group
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wire up group module Add server implementation of group module
6 participants