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

move Un/DelegateCoins to x/staking #4056

Open
4 tasks
fedekunze opened this issue Apr 5, 2019 · 5 comments
Open
4 tasks

move Un/DelegateCoins to x/staking #4056

fedekunze opened this issue Apr 5, 2019 · 5 comments

Comments

@fedekunze
Copy link
Collaborator

Summary

Discuss whether DelegateCoins and UndelegateCoins should live within the bank or staking module.

Problem Definition

Currently the bank keeper handles the delegation and delegation of coins. The thing with this is that as an SDK dev I don't want to use the staking module (say by implementing an own PoA or PoW module). Then this 2 functions are useless:

// Keeper defines a module interface that facilitates the transfer of coins
// between accounts.
type Keeper interface {
SendKeeper
SetCoins(ctx sdk.Context, addr sdk.AccAddress, amt sdk.Coins) sdk.Error
SubtractCoins(ctx sdk.Context, addr sdk.AccAddress, amt sdk.Coins) (sdk.Coins, sdk.Tags, sdk.Error)
AddCoins(ctx sdk.Context, addr sdk.AccAddress, amt sdk.Coins) (sdk.Coins, sdk.Tags, sdk.Error)
InputOutputCoins(ctx sdk.Context, inputs []Input, outputs []Output) (sdk.Tags, sdk.Error)
DelegateCoins(ctx sdk.Context, addr sdk.AccAddress, amt sdk.Coins) (sdk.Tags, sdk.Error)
UndelegateCoins(ctx sdk.Context, addr sdk.AccAddress, amt sdk.Coins) (sdk.Tags, sdk.Error)
}

cc: @rigelrozanski @cwgoes @alessio @jackzampolin


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@fedekunze fedekunze changed the title Should (un)delegation be handled on the bank or staking module ? Should (un)delegation of coins be handled on the bank or staking module ? Apr 5, 2019
@alexanderbez
Copy link
Contributor

alexanderbez commented Apr 5, 2019

The staking keeper when then need access to the auth's account keeper...just for this sole purpose. The staking keeper already needed the bank keeper, hence we decided to implement on such. Otherwise, the staking keeper would need to get the account, do the arithmetic, and set the coins. Sounds like a banking operation to me.

@alessio
Copy link
Contributor

alessio commented Apr 5, 2019

@alexanderbez I don't think @fedekunze meant to call into question the design rationale, which is very clear indeed. However in his use case of develping a PoA dapp, as an SDK end-user he wants to use bank features and at the same time avoids exposing staking delegation features.

(I'm CC'ing @sunnya97 @mossid @sabau too)

@alexanderbez
Copy link
Contributor

alexanderbez commented Apr 5, 2019

Sure, so just don't simply use those features 😉. That or update the staking module to do accounting.

@rigelrozanski
Copy link
Contributor

Yeah I think it could make sense to include these accounting features within the staking module - the ultimate home of delegation logic is in fact staking. Ideally we could somehow abstract out accounting patterns within bank so that any duplicate accounting patterns required for use within staking for the delegation logic can simply come directly from bank.

This said, I think that the fact that the initial build of the delegation logic has been added to bank is totally acceptable as the MVP. This issue simply describes the next evolution

@fedekunze fedekunze changed the title Should (un)delegation of coins be handled on the bank or staking module ? move Un/DelegateCoins to x/staking Jul 16, 2019
@github-actions
Copy link
Contributor

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants