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

Batch rewards distribution #125

Merged
merged 25 commits into from
Sep 28, 2023
Merged

Batch rewards distribution #125

merged 25 commits into from
Sep 28, 2023

Conversation

uint
Copy link
Contributor

@uint uint commented Sep 14, 2023

Closes #77

There's this comment in the ticket:

This requires much more complex withdraw logic in the virtual-staking contract, and first we need to be able to cover that with unit tests.

Given that the ticket talks about batching distribution and not withdrawing, I don't understand the need for changing withdraw logic. I feel like maybe there's an implication withdrawing could be optimized too, but I have no way of knowing for sure what was meant. If I'm missing something or there's further work to be done, please let me know.

@uint uint changed the title converter: batch rewards distribution Batch rewards distribution Sep 15, 2023
@uint
Copy link
Contributor Author

uint commented Sep 15, 2023

This is only missing tests on provider site, but I'm going to first try and add better abstractions to provider tests.

@uint uint force-pushed the 77-batch-distribute-rewards branch from cfe2704 to b47b80b Compare September 18, 2023 19:45
@uint
Copy link
Contributor Author

uint commented Sep 18, 2023

@maurolacy I've noticed non-batch distribution returns no error when an invalid validator is provided. Is that intended? Do we want the same behavior for batch?

@maurolacy
Copy link
Collaborator

@maurolacy I've noticed non-batch distribution returns no error when an invalid validator is provided. Is that intended? Do we want the same behavior for batch?

That's OK, because that validators list comes from the blockchain. Take a look at the virtual-staking contract, the handle_epoch and reply_rewards methods gather the rewards automatically from the blockchain.

Copy link
Collaborator

@maurolacy maurolacy left a comment

Choose a reason for hiding this comment

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

Good start. Please adjust / remove tests, as invalid validators shouldn't be possible.

packages/apis/src/ibc/packet.rs Show resolved Hide resolved
contracts/consumer/converter/src/contract.rs Outdated Show resolved Hide resolved
contracts/consumer/converter/src/contract.rs Show resolved Hide resolved
contracts/provider/external-staking/src/ibc.rs Outdated Show resolved Hide resolved
@maurolacy
Copy link
Collaborator

Given that the ticket talks about batching distribution and not withdrawing, I don't understand the need for changing withdraw logic. I feel like maybe there's an implication withdrawing could be optimized too, but I have no way of knowing for sure what was meant. If I'm missing something or there's further work to be done, please let me know.

What's missing is to send a DistributeBatch message from the virtual-staking contract to the converter, instead of a bunch of Distribute messages.

I'm realising now that this might be complex to do. Let's discuss details offline.

@maurolacy
Copy link
Collaborator

maurolacy commented Sep 19, 2023

@maurolacy I've noticed non-batch distribution returns no error when an invalid validator is provided. Is that intended? Do we want the same behavior for batch?

That's OK, because that validators list comes from the blockchain. Take a look at the virtual-staking contract, the handle_epoch and reply_rewards methods gather the rewards automatically from the blockchain.

What we can do to err on the safe side, is to add a sender check to the distribute_reward / distribute_rewards handlers, so that the only authorised caller is the virtual-staking contract.

That way we'll prevent malicious actors on the Consumer sending small amounts with invalid validators to distribute, to mess with our mesh security impl.

Update: That, or check that the validator is valid. This is related to #123 by the way. Let's discuss offline.

@uint
Copy link
Contributor Author

uint commented Sep 19, 2023

@maurolacy How do we test the code in virtual-staking currently?

@maurolacy
Copy link
Collaborator

maurolacy commented Sep 20, 2023

@maurolacy How do we test the code in virtual-staking currently?

Good question. Short answer is, we don't have a good way to test some parts of it at this level at the moment. That's why it's mostly untested.
Feel free to write some unit tests if you think it's worth it / useful. But some parts, like the reply handler behaviour, are difficult to test in this setup.

By the way, now that Sylvia has support for custom queries, we can test the sudo entry point better (there's a FIXME in the code for that). But this is another issue.

On the bright side, the rewards gathering and distribution code was tested as part of mesh-security integration on a devnet, and it works.

@uint
Copy link
Contributor Author

uint commented Sep 20, 2023

@maurolacy How do we test the code in virtual-staking currently?

Good question. Short answer is, we don't have a good way to test some parts of it at this level at the moment. That's why it's mostly untested. Feel free to write some unit tests if you think it's worth it / useful. But some parts, like the reply handler behaviour, are difficult to test in this setup.

I have ideas about how to test this, but they might require some refactoring and bloat this PR even more. I think I'd be more comfortable getting this merged and starting a new PR.

@maurolacy
Copy link
Collaborator

Looks good. Is this ready for (final) review? Can you mark it as such? Thanks.

@uint
Copy link
Contributor Author

uint commented Sep 21, 2023

Looks good. Is this ready for (final) review? Can you mark it as such? Thanks.

I was going to give it a once-over before doing that.

@uint uint force-pushed the 77-batch-distribute-rewards branch from 81a5b22 to 8c102c4 Compare September 21, 2023 08:12
@uint uint marked this pull request as ready for review September 21, 2023 08:18
@uint uint requested a review from maurolacy September 21, 2023 08:18
Copy link
Collaborator

@maurolacy maurolacy left a comment

Choose a reason for hiding this comment

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

Reviewed the virtual-staking integration and found some issues. Will review the rest later.

contracts/consumer/virtual-staking/src/contract.rs Outdated Show resolved Hide resolved
@uint uint requested a review from maurolacy September 25, 2023 09:24
Copy link
Collaborator

@maurolacy maurolacy left a comment

Choose a reason for hiding this comment

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

Looks better, but I think that there are still a couple of issues with the main logic.

contracts/consumer/virtual-staking/src/contract.rs Outdated Show resolved Hide resolved
contracts/consumer/virtual-staking/src/contract.rs Outdated Show resolved Hide resolved
contracts/consumer/virtual-staking/src/contract.rs Outdated Show resolved Hide resolved
@uint
Copy link
Contributor Author

uint commented Sep 27, 2023

I have ideas about how to test this, but they might require some refactoring and bloat this PR even more. I think I'd be more comfortable getting this merged and starting a new PR.

Since the tests didn't really require refactoring (just a bunch of new code), and the lack of them makes this PR development massively painful, I'm going to merge the tests here after all. Sorry about the LoC!

Copy link
Collaborator

@maurolacy maurolacy left a comment

Choose a reason for hiding this comment

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

LGTM. Nice tests!

funds: vec![reward],
let new_reward_amount = total - BATCH.total(deps.storage)?;

let all_rewards = |storage| {
Copy link
Collaborator

Choose a reason for hiding this comment

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

This logic is now more complex than before. 🙂

OK, I trust this is correct, based on the tests below.

Nice way of testing it, by the way.

@uint uint merged commit d501412 into main Sep 28, 2023
2 checks passed
@maurolacy maurolacy deleted the 77-batch-distribute-rewards branch October 12, 2023 11:41
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.

Use batch distribute_rewards for cross-chain distribution efficiency
2 participants