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

Test epoch processing rewards/penalties #1231

Closed
9 tasks
protolambda opened this issue Jun 29, 2019 · 4 comments
Closed
9 tasks

Test epoch processing rewards/penalties #1231

protolambda opened this issue Jun 29, 2019 · 4 comments

Comments

@protolambda
Copy link
Contributor

This is a select set of tests isolated from the other tests that are included in the spec-freeze itself. Tests quality and feature-completeness was prioritized over rushing these in. Now after spec-freeze, the goal is to provide these as an addition (perfectly backwards compatible / not touching the spec itself), to complete the coverage.

Part of this functionality is already covered by the block tests and others. But to complete it, we need to dig into simulation of attestation (as done for earlier epoch processing justification/finalization tests), and crosslinks. Then see if we can cleanly model the balance changes for assertions.

TODO in process_rewards_and_penalties:

  • matching penalties/rewards
    • matching head: penalty, reward, none, both
    • matching target: penalty, reward, none, both
    • matching source: penalty, reward, none, both
  • proposer inclusion delay
  • inactivity penalty
  • crosslink committee:
    • penalty if not in committee, reward if in committee
    • no crosslink, empty participation, everyone penalty
@JustinDrake
Copy link
Contributor

Are these tests still TODO?

@protolambda
Copy link
Contributor Author

At the time it was considered too convoluted to setup tests for rewards/penalties, since the spec itself doesn't really isolate the computation from that of the chain inputs. But crosslinks have been removed, so it should be better now. I can pick it up now, but also want the phase1 pr merged first (and remaining complexities with factoring in phase 1 functionality). Maybe close this in favor of a phase1 ready testing issue?

@JustinDrake
Copy link
Contributor

Maybe close this in favor of a phase1 ready testing issue?

Sure, go ahead if you think that's the way forward :) I'm mainly doing a pass on old/stale issues.

@protolambda
Copy link
Contributor Author

Closing in favor of #1526

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

2 participants