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

tests: 🧨 mock consensus exercises staking component #3995

Closed
26 tasks done
cratelyn opened this issue Mar 11, 2024 · 4 comments
Closed
26 tasks done

tests: 🧨 mock consensus exercises staking component #3995

cratelyn opened this issue Mar 11, 2024 · 4 comments
Assignees
Labels
A-mock-consensus Area: Relates to the mock consensus engine
Milestone

Comments

@cratelyn
Copy link
Contributor

cratelyn commented Mar 11, 2024

in #3588, we are building testing facilities for our App. we should write tests using the mock consensus engine that exercise the staking component.

we should write a test (or collection thereof) that performs the following:

  • 1. start with a single validator, using the auto_app_state flow
  • 2. run the chain for 1000 blocks
  • 3. make a tx that defines a new validator, register its consensus signing key with the engine
  • 4. after executing (3), check that:
    • 4a. the validator appeared on chain in the defined state
      • "this is a negative test: we want to make sure that just because someone defined a validator, we don't actually do anything in the staking component's logic"
    • 4b. the validator set did not change ("defined" validators don't affect staking logic)
  • 5. make a tx that delegates more than the minimum amount (where is this defined?) to the new validator
  • 6. after executing (5), check that:
    • 6a. no changes to the validator set occur immediately
      • "this is another negative test, we want to be checking that (un)delegations are queued for the epoch transition rather than being effected immediately"
    • 6b. kate: the amount of delegation tokens looks correct
  • 7. run to the end of the epoch (can hardcode or check epoch length), then check
    • 7a. the validator becomes Active (it will probably skip Inactive because only one other validator)
    • 7b. the two validators have different exchange rates
      • "this is also a negative test, we want to make sure that the validator exchange rate mechanism is actually doing stuff, we expect that the two validators would have different rates because the second validator is created later and the chain has already "warmed up" and run through a few epochs"
  • 8. run 1000 blocks into the future, then check
    • 8a. the new validator's uptime is being tracked correctly
      • "check that the mock engine is actually feeding correct-enough information to the application. the validator uptime is recorded by the app based on what validators were recorded as signing the block. i would expect there would be failures here when we first write this, and that resolving them would require co-development of the mock engine and the test. this will be a site of requirements discovery"
  • 9. make a tx that undelegates some of the delegation tokens
  • 10. after executing (9), check that:
    • 10a. the client gets unbonding tokens
    • 10b. the validator's voting power does not change immediately
    • 10c. kate: the amount of undelegation tokens looks correct
  • 11. run to the end of the epoch, then check
    • 11a. the validator's voting power has decreased
      • "(10a/b,11a) are again checking that undelegations are only processed at epoch boundaries"
  • 12. run forward for the length of the unbonding period
  • 13. make a tx that claims the unbonding tokens
  • 14. after executing (12), check that:
    • 14a. the client gets staking tokens out

@cratelyn cratelyn added the A-mock-consensus Area: Relates to the mock consensus engine label Mar 11, 2024
@cratelyn cratelyn self-assigned this Mar 11, 2024
@github-project-automation github-project-automation bot moved this to 🗄️ Backlog in Penumbra Mar 11, 2024
@cratelyn cratelyn moved this from 🗄️ Backlog to In progress in Penumbra Mar 11, 2024
@cratelyn cratelyn added this to the Sprint 2 milestone Mar 11, 2024
cratelyn added a commit that referenced this issue Mar 12, 2024
fixes #3933.

this introduces a `fast_forward` method to a test node, allowing tests
using the mock consensus engine (#3588) to fast forward a certain number
of blocks.

the existing `mock_consensus_can_send_a_sequence_of_empty_blocks` test
is rewritten to make use of this method.

this is done in service of #3995.

---

* #3588
* #3933
* #3995
cratelyn added a commit that referenced this issue Mar 12, 2024
fixes #3933.

this introduces a `fast_forward` method to a test node, allowing tests
using the mock consensus engine (#3588) to fast forward a certain number
of blocks.

the existing `mock_consensus_can_send_a_sequence_of_empty_blocks` test
is rewritten to make use of this method.

this is done in service of #3995.

---

* #3588
* #3933
* #3995
cratelyn added a commit that referenced this issue Mar 12, 2024
fixes #3933.

this introduces a `fast_forward` method to a test node, allowing tests
using the mock consensus engine (#3588) to fast forward a certain number
of blocks.

the existing `mock_consensus_can_send_a_sequence_of_empty_blocks` test
is rewritten to make use of this method.

this is done in service of #3995.

---

* #3588
* #3933
* #3995
@cratelyn
Copy link
Contributor Author

xref #4009

cratelyn added a commit that referenced this issue Mar 13, 2024
this patches the mock consensus `TestNode::end_block` method so that the
height of these requests does not stay at 1.

this is needed for staking tests, see #3995.

* #3588
* #4001
* #3995
* #3840
cratelyn added a commit that referenced this issue Mar 13, 2024
see #4001, #3995.

this adds tracing telemetry to improve the observability of checking
supply for an asset. with complete trace level logging enabled for the
staking, mock consensus, app, and shielded pool crates, this looks like:

```
  2024-03-13T19:39:50.613399Z  WARN penumbra_shielded_pool::component::supply: could not find token supply for asset
    at crates/core/component/shielded-pool/src/component/supply.rs:32
    in penumbra_stake::component::stake::total_active_stake
    in penumbra_stake::component::epoch_handler::end_epoch with index: 0
    in penumbra_stake::component::stake::staking
    in penumbra_app::app::end_block with height: 718
    in penumbra_mock_consensus::abci::end_block
    in penumbra_mock_consensus::block::execute with height: 718, time: 1710358790
    in penumbra_mock_consensus::executing empty block with i: 717
    in penumbra_mock_consensus::fast_forward with blocks: 1000, fast_forward.blocks: 1000
    in mock_consensus_staking::fast forwarding test node to next epoch
```

NB: this is with trace level logging enabled, many of these spans will
not appear if run at e.g. info level.
cratelyn added a commit that referenced this issue Mar 15, 2024
this patches the mock consensus `TestNode::end_block` method so that the
height of these requests does not stay at 1.

this is needed for staking tests, see #3995.

* #3588
* #4001
* #3995
* #3840
cratelyn added a commit that referenced this issue Mar 15, 2024
this patches the mock consensus `TestNode::end_block` method so that the
height of these requests does not stay at 1.

this is needed for staking tests, see #3995.

* #3588
* #4001
* #3995
* #3840
cratelyn added a commit that referenced this issue Mar 18, 2024
fixes #3966. fixes #3908. fixes _part of_ #3995.

this branch introduces the first steps towards mock consensus (#3588)
testing of the staking component (#3845).

this defines a validator after genesis, and then shows that it does
_not_ enter the consensus set. #3966 is addressed in this branch so that
the existing genesis validator correctly enters the consensus set, and
so that we can successfully progress to the second epoch.

subsequent changes will exercise delegating to this validator in the
`mock_consensus_can_define_and_delegate_to_a_validator`.

#### ✨ changes

* alters `with_penumbra_auto_app_state` so that it adds an allocation of
delegation tokens to the shielded pool component's genesis content.

* extends `generate_penumbra_validator` so that it generates a real
spend key, and returns an `Allocation` for the generated validator.
_(see #3966)_

* adds a new `mock_consensus_can_define_and_delegate_to_a_validator`
test that defines a post-genesis validator. _(see #3908)_

* defines a new `ConsensusIndexRead::get_consensus_set()` method, which
collects all of the identity keys returned by `consensus_set_stream`.

* lowers the events in
`penumbra_mock_consensus::block::Builder::execute()` to trace-level
events.

* `penumbra_mock_consensus::builder::Builder` will now log a warning if
values may be errantly rewritten by the builder methods.

* `TestNode::fast_forward` sets its `i` span field to `1..n`, rather
than `0..n-1`.

---

#### :link: related

* #4009
* #4010
* #4011
* #4017
* #4027
* #4028
* #4029
* #3966
* #3908
* #3588

---------

Co-authored-by: Henry de Valence <hdevalence@penumbralabs.xyz>
@cratelyn cratelyn modified the milestones: Sprint 2, Sprint 3 Mar 18, 2024
@cratelyn
Copy link
Contributor Author

updated the description of this issue to represent a checklist, to better track incremental steps towards completion. with #4001 merged, we are now progressing to the exciting stages of this work. 🎉

@cratelyn cratelyn modified the milestones: Sprint 3, Sprint 2 Mar 18, 2024
@cratelyn
Copy link
Contributor Author

#4030 may conflict with work on 8a.

cratelyn added a commit that referenced this issue Mar 19, 2024
 ### 🚠 overview

in #4001 we added a test for the staking component (_see also #3995,
and #3588_).

this shortens the epoch length, so that this test runs in less time, and
importantly, so that debugging test failures does not entail sifting
through many log lines.

 ### ➕ changes

* manually construct an `AppState` so that we use a shorter epoch. this
  test involves waiting for multiple epochs to pass, which takes
  many seconds with the default length of 719, see:
  <https://github.com/penumbra-zone/penumbra/blob/8be8e8266b312c2a9eb1b1522a937e8df12f3a4f/crates/core/component/sct/src/params.rs#L41>

* `TestNode<C>::fast_forward` now accepts a u64, mirroring the type used
  in the sct parameters.

 ### 🏃 runtime

on `main`...

```
    Starting 1 test across 1 binary
        PASS [  12.646s] penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
------------
     Summary [  12.647s] 1 test run: 1 passed, 0 skipped
```

after these changes...

```
    Starting 1 test across 1 binary
        PASS [   0.420s] penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
------------
     Summary [   0.420s] 1 test run: 1 passed, 0 skipped
```

 ### 🥙 log volume

on `main`...

```
; RUST_LOG='info' cargo nextest run -p penumbra-app --test mock_consensus_staking --no-capture | wc -l
    Finished test [unoptimized + debuginfo] target(s) in 0.16s
    Starting 1 test across 1 binary
       START             penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
        PASS [  12.185s] penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
------------
     Summary [  12.185s] 1 test run: 1 passed, 0 skipped
46082
```

```
; RUST_LOG='info' cargo nextest run -p penumbra-app --test mock_consensus_staking --no-capture | wc -l
    Finished test [unoptimized + debuginfo] target(s) in 0.15s
    Starting 1 test across 1 binary
       START             penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
        PASS [   0.416s] penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
------------
     Summary [   0.416s] 1 test run: 1 passed, 0 skipped
450
```
cratelyn added a commit that referenced this issue Mar 19, 2024
### 🚠 overview

in #4001 we added a test for the staking component (_see also #3995, and
#3588_).

this shortens the epoch length, so that this test runs in less time, and
importantly, so that debugging test failures does not entail sifting
through many log lines.

 ### ➕ changes

* manually construct an `AppState` so that we use a shorter epoch. this
test involves waiting for multiple epochs to pass, which takes many
seconds with the default length of 719, see:
<https://github.com/penumbra-zone/penumbra/blob/8be8e8266b312c2a9eb1b1522a937e8df12f3a4f/crates/core/component/sct/src/params.rs#L41>

* `TestNode<C>::fast_forward` now accepts a u64, mirroring the type used
in the sct parameters.

 ### 🏃 runtime

on `main`...

```
    Starting 1 test across 1 binary
        PASS [  12.646s] penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
------------
     Summary [  12.647s] 1 test run: 1 passed, 0 skipped
```

after these changes...

```
    Starting 1 test across 1 binary
        PASS [   0.420s] penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
------------
     Summary [   0.420s] 1 test run: 1 passed, 0 skipped
```

 ### 🥙 log volume

on `main`...

```
; RUST_LOG='info' cargo nextest run -p penumbra-app --test mock_consensus_staking --no-capture | wc -l
    Finished test [unoptimized + debuginfo] target(s) in 0.16s
    Starting 1 test across 1 binary
       START             penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
        PASS [  12.185s] penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
------------
     Summary [  12.185s] 1 test run: 1 passed, 0 skipped
46082
```

```
; RUST_LOG='info' cargo nextest run -p penumbra-app --test mock_consensus_staking --no-capture | wc -l
    Finished test [unoptimized + debuginfo] target(s) in 0.15s
    Starting 1 test across 1 binary
       START             penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
        PASS [   0.416s] penumbra-app::mock_consensus_staking mock_consensus_can_define_and_delegate_to_a_validator
------------
     Summary [   0.416s] 1 test run: 1 passed, 0 skipped
450
```
cratelyn added a commit that referenced this issue Mar 19, 2024
see #3995.

this test now delegates to, and then undelegates from, a validator.

this does not yet include all of the assertions we would like to
exercise in this test, but it does show that a validator correctly
progresses through the active and defined states.

in further work, we will fill out the other assertions described
in #3995, particularly w.r.t. voting power and validator uptime.
cratelyn added a commit that referenced this issue Mar 19, 2024
see #3995.

this test now delegates to, and then undelegates from, a validator.

this does not yet include all of the assertions we would like to
exercise in this test, but it does show that a validator correctly
progresses through the active and defined states.

in further work, we will fill out the other assertions described
in #3995, particularly w.r.t. voting power and validator uptime.
cratelyn added a commit that referenced this issue Mar 20, 2024
see #3995.

this test now delegates to, and then undelegates from, a validator.

this does not yet include all of the assertions we would like to
exercise in this test, but it does show that a validator correctly
progresses through the active and defined states.

in further work, we will fill out the other assertions described
in #3995, particularly w.r.t. voting power and validator uptime.
cratelyn added a commit that referenced this issue Mar 20, 2024
addresses §7.b in #3995.

this introduces new assertions so that the
`mock_consensus_can_define_and_delegate_to_a_validator` test exercises
that the staking component is calculating different rates for validators
that were created at different times.
cratelyn added a commit that referenced this issue Mar 20, 2024
addresses §7.b in #3995.

this introduces new assertions so that the
`mock_consensus_can_define_and_delegate_to_a_validator` test exercises
that the staking component is calculating different rates for validators
that were created at different times.
cratelyn added a commit that referenced this issue Mar 20, 2024
addresses §7.b in #3995.

this introduces new assertions so that the
`mock_consensus_can_define_and_delegate_to_a_validator` test exercises
that the staking component is calculating different rates for validators
that were created at different times.
@aubrika aubrika modified the milestones: Sprint 2, Sprint 3 Mar 25, 2024
cratelyn added a commit that referenced this issue Mar 26, 2024
**NB:** this is based on #4099.

this adds test coverage, complementary to the work in #4061, which
asserts that we properly track the _affirmative_ case of validators
signing blocks.

fixes #4040. see #3995.
cratelyn added a commit that referenced this issue Mar 28, 2024
see #3995.

this addresses points 10b and 11a in #3995. this adds additional
assertions to the `app_can_define_and_delegate_to_a_validator` test,
which ensure that the validator's voting power changes as expected.
cratelyn added a commit that referenced this issue Apr 1, 2024
see #3995.

this addresses points 10b and 11a in #3995. this adds additional
assertions to the `app_can_define_and_delegate_to_a_validator` test,
which ensure that the validator's voting power changes as expected.

#### checklist before requesting a review

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

  > test changes only
cratelyn added a commit that referenced this issue Apr 1, 2024
this introduces additional test coverage for the staking component,
examining the mock client's notes during delegation, the unbonding
period, and after claiming an undelegation.

* #4115
* #3995
@cratelyn
Copy link
Contributor Author

cratelyn commented Apr 1, 2024

this work is now complete. there is certainly more coverage that we can continue to write in the future, but for now we have working examples of exercising the application's staking component. 🎉

@cratelyn cratelyn closed this as completed Apr 1, 2024
@github-project-automation github-project-automation bot moved this from In progress to Done in Penumbra Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-mock-consensus Area: Relates to the mock consensus engine
Projects
Archived in project
Development

No branches or pull requests

2 participants