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

BM-3: feat(epoching): Epoching module setup #2

Merged
merged 13 commits into from
Jun 13, 2022

Conversation

SebastianElvis
Copy link
Member

@SebastianElvis SebastianElvis commented Jun 8, 2022

Fixes BM-11 under BM-3.

This PR adds the vanilla epoching module.
It makes the following modifications atop main:

Future work on the epoching module includes other child issues in https://babylon-chain.atlassian.net/browse/BM-3 and will be done in separate PRs.

@SebastianElvis SebastianElvis requested review from aakoshh and gitferry and removed request for aakoshh and gitferry June 8, 2022 01:55
@aakoshh aakoshh changed the title feat(epoching): Epoching module setup BM-3: feat(epoching): Epoching module setup Jun 9, 2022
Copy link
Contributor

@aakoshh aakoshh left a comment

Choose a reason for hiding this comment

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

That's an impressive amount of boilerplate out of the way! Nice work, it will surely make the rest of the PRs easier to grasp 👏

I wonder why the whole app.go file shows as each line has changed. Did you insert your edits manually, or was it somehow generated by a tool? How about the rest of the files?

I only have some clarification questions.

// GenesisState defines the epoching module's genesis state.
message GenesisState {
Params params = 1 [(gogoproto.nullable) = false];
// this line is used by starport scaffolding # genesis/proto/state
Copy link
Contributor

Choose a reason for hiding this comment

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

Just looking at https://github.com/cosmos/cosmos-sdk/blob/v0.45.4/proto/cosmos/staking/v1beta1/genesis.proto#L16-L38 it appears like they make room in the genesis file to carry over state from a previous chain, like a hard fork. For example unbonding_delegations would not make sense at the very first genesis, surely nobody is unbonding yet, but if we want to restart a new chain from the ashes of the old, it can be used to restore state.

So I wonder if there should be similar entries for delayed staking transactions and BLS keys here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Agree. In the epoching module such historical states may include the delayed messages and the epoch number (if the epoch length is a variable).

x/epoching/keeper/params.go Outdated Show resolved Hide resolved

const (
// ModuleName defines the module name
ModuleName = "epoching"
Copy link
Contributor

Choose a reason for hiding this comment

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

Hopefully this will never clash with the one in the cosmos SDK. Like during a migration, if we want to enable that one in the future.

Copy link
Member Author

Choose a reason for hiding this comment

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

In that case perhaps we can rename our epoching module as something like bblepoching when importing it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's leave it for now, so it matches, then we'll see. In Osmosis these are called epochs.


)


Copy link
Contributor

Choose a reason for hiding this comment

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

app/app.go Show resolved Hide resolved
app/app.go Outdated Show resolved Hide resolved
app/app.go Outdated
Comment on lines 393 to 405
app.mm.SetOrderEndBlockers(
crisistypes.ModuleName, govtypes.ModuleName, stakingtypes.ModuleName,
capabilitytypes.ModuleName, authtypes.ModuleName, banktypes.ModuleName, distrtypes.ModuleName,
slashingtypes.ModuleName, minttypes.ModuleName,
genutiltypes.ModuleName, evidencetypes.ModuleName, authz.ModuleName,
feegrant.ModuleName,
paramstypes.ModuleName, upgradetypes.ModuleName, vestingtypes.ModuleName,
/*
TODO: add bbl module
testbblmoduletypes.ModuleName,
*/
epochingtypes.ModuleName,
)
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe worth leaving a comment that if we don't want staking to run at the end of each block, we should remove stakingtypes.ModuleName from app.mm.OrderEndBlockers after this call (it's a public field).

One possible issue with the way it is now is if in the last block where we want to run epoching.EndBlock, if that returns a non-empty set of validator updates, and the staking.EndBlock also returns a non-empty set, then Tendermint will panic. It only allows one module to return a changeset. With the current order, staking might return a changeset if there was slashing.

So we can either:

  1. Never call staking.EndBlock, only epoching.EndBlock
  2. Make sure we call epoching.EndBlock first but only to dequeue the delayed staking requests, and then let staking.EndBlock take care of executing them and return the changeset.

But because we only want the power transfer to happen, not the processing of the unbonding queues, we probably can't allow staking to run as-is.

@SebastianElvis
Copy link
Member Author

I wonder why the whole app.go file shows as each line has changed. Did you insert your edits manually, or was it somehow generated by a tool? How about the rest of the files?

I inserted the lines in app.go and app_test.go manually according to the comments. It seems that throughout the current code base, app.go and app_test.go are the only two files that require modifications when adding a new module.

@SebastianElvis
Copy link
Member Author

Thanks for the review Akosh! I have fixed or replied the comments. Feel free to re-review.

Copy link
Contributor

@aakoshh aakoshh left a comment

Choose a reason for hiding this comment

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

Cool, thanks for following up on all my comments 👍

)

type msgServer struct {
Keeper
Copy link
Member

Choose a reason for hiding this comment

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

This shoud be a reference to a keeper k Keeper.

Copy link
Contributor

Choose a reason for hiding this comment

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

Good catch!

@@ -0,0 +1,14 @@
syntax = "proto3";
package babylonchain.babylon.epoching;
Copy link
Member Author

Choose a reason for hiding this comment

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

Suggested change
package babylonchain.babylon.epoching;
package babylon.epoching;

Copy link
Member

Choose a reason for hiding this comment

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

Or babylon.epoching.v1 if we want versioning for those.

@vitsalis
Copy link
Member

Maybe we should also remove the comments related to ignite scaffolding.

@SebastianElvis
Copy link
Member Author

Maybe we should also remove the comments related to ignite scaffolding.

Can we keep them at the moment? Just in case if we want to create stuff (CLI, message types, interfaces) by using ignite.

@SebastianElvis
Copy link
Member Author

SebastianElvis commented Jun 13, 2022

Thanks for the comments Vitalis! I have addressed them and rebased this PR wrt main. Feel free to re-review.

Copy link
Member

@vitsalis vitsalis left a comment

Choose a reason for hiding this comment

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

LGTM!

@SebastianElvis SebastianElvis merged commit f91eedc into main Jun 13, 2022
@SebastianElvis SebastianElvis deleted the add-epoching-module branch June 13, 2022 11:19
KonradStaniec pushed a commit that referenced this pull request Oct 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants