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: claim rewards #48

Open
wants to merge 16 commits into
base: main
Choose a base branch
from
Open

feat: claim rewards #48

wants to merge 16 commits into from

Conversation

h3lio5
Copy link
Contributor

@h3lio5 h3lio5 commented Nov 13, 2024

Changes:

  • added new ClaimRewards tx method
  • removed reward payout, amount withdraw from subscription module's EndBlock
  • after action now happens on an epoch basis instead of block basis
  • updated all tests to reflect these changes
  • added new WithdrawResidue tx method

fixes #40

@h3lio5 h3lio5 marked this pull request as ready for review November 20, 2024 06:52
Copy link
Member

@d-roak d-roak left a comment

Choose a reason for hiding this comment

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

will finish review later

config.yml Outdated Show resolved Hide resolved
config.yml Outdated Show resolved Hide resolved
@@ -25,6 +25,8 @@ service Msg {
rpc JoinDeal (MsgJoinDeal ) returns (MsgJoinDealResponse );
rpc LeaveDeal (MsgLeaveDeal ) returns (MsgLeaveDealResponse );
rpc SubmitProgress (MsgSubmitProgress ) returns (MsgSubmitProgressResponse );
rpc claimRewards (MsgClaimRewards ) returns (MsgClaimRewardsResponse );
rpc withdrawResidue (MsgWithdrawResidue ) returns (MsgWithdrawResidueResponse );
Copy link
Member

Choose a reason for hiding this comment

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

what's this for?

Copy link
Contributor Author

@h3lio5 h3lio5 Nov 20, 2024

Choose a reason for hiding this comment

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

claimRewards: providers claiming rewards
withdrawResidue: deal creator withdrawing any residue (a bit of context: rewards split evenly between epochs, if no one claims rewards before deal_expiry_claim_window (7 days but we can change it), the creator can withdraw it)

Choose a reason for hiding this comment

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

I think we disapproved this, provider should be able to withdraw whenever they want.

x/subscription/keeper/msg_progress.go Show resolved Hide resolved
@@ -25,6 +25,8 @@ service Msg {
rpc JoinDeal (MsgJoinDeal ) returns (MsgJoinDealResponse );
rpc LeaveDeal (MsgLeaveDeal ) returns (MsgLeaveDealResponse );
rpc SubmitProgress (MsgSubmitProgress ) returns (MsgSubmitProgressResponse );
rpc claimRewards (MsgClaimRewards ) returns (MsgClaimRewardsResponse );
rpc withdrawResidue (MsgWithdrawResidue ) returns (MsgWithdrawResidueResponse );

Choose a reason for hiding this comment

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

I think we disapproved this, provider should be able to withdraw whenever they want.

x/subscription/keeper/msg_progress.go Outdated Show resolved Hide resolved
utils/utils.go Outdated Show resolved Hide resolved
x/subscription/keeper/deal.go Show resolved Hide resolved
if int64(msg.EndBlock) < ctx.BlockHeight() {
return nil, errorsmod.Wrap(sdkerrors.ErrInvalidRequest, "end block must be greater than current block height")
if msg.NumEpochs != 0 {
if deal.StartBlock+msg.NumEpochs*deal.EpochSize < currentBlock {

Choose a reason for hiding this comment

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

Let's discuss this : wouldn't it be better to append the epochs to the existing epochs : so for me It could be something like deal.EndBlock + msg.NumEpochs * deal.EpochSize to have the new EndBlock

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is to prevent the deal duration from shrinking in size such that the new endblock is lower than current block, i.e., you can't set the end block to an expired block haha.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

to clarify, we are not storing the end block anywhere. The above check is just to prevent shrinking the deal duration such that it is expired (i.e., new end_block < current_block)

x/subscription/keeper/progress.go Outdated Show resolved Hide resolved
@@ -29,15 +31,18 @@ func (k msgServer) SubmitProgress(goCtx context.Context, msg *types.MsgSubmitPro
return nil, errorsmod.Wrap(sdkerrors.ErrUnauthorized, "only the provider can submit progress")
}

deal, found := k.GetDeal(ctx, subscription.DealId)
currentEpoch := (currentBlock - deal.StartBlock + 1) / deal.EpochSize
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we have a utility function to compute the current epoch?

Choose a reason for hiding this comment

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

I thought we had it.

utils/utils.go Outdated Show resolved Hide resolved
StartBlock: subscriptionStartBlock,
EndBlock: deal.EndBlock,
StartEpoch: subscriptionStartEpoch,
EndEpoch: (deal.EpochSize*deal.NumEpochs + 1) / deal.EpochSize,
Copy link
Contributor

Choose a reason for hiding this comment

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

Make it easier to calculate: EndEpoch = subscriptionStartEpoch + numEpochs - 1.

deal.Status = types.Deal_ACTIVE
} else {
subscriptionStartBlock = deal.StartBlock
// start from the first epoch
subscriptionStartEpoch = 0
Copy link
Contributor

Choose a reason for hiding this comment

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

If subscriptionStartEpoch has an index of 1, it should have a value of 1 here.

// 7 days equivalent epochs
const DEAL_EXPIRY_CLAIM_WINDOW = 144

func ConvertBlockToEpoch(blockOffset, epochSize uint64) uint64 {
Copy link
Contributor

Choose a reason for hiding this comment

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

We need to correct the formula in ConvertBlockToEpoch and use it globally!

progressSize := uint64(len(hashesSet))
progressDeal = getUpdatedProgressDeal(progressDeal, provider, progressSize, deal.RewardPerEpoch, currentEpoch)
k.SetProgressDealAtEpoch(ctx, subscription.DealId, currentEpoch, progressDeal)
k.AddProgressEpochsProvider(ctx, provider, subscriptionId, currentEpoch)
return &types.MsgSubmitProgressResponse{}, nil
}

initialProgressSize := len(progress)
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't we move the line initialProgressSize := len(progress) right before the !found if-else case?

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.

Add a new Tx method to claim rewards
4 participants