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.

Sign up for GitHub

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

Jump to bottom

Extend pool monitoring code to store retirements in the DB. #1817

Closed
2 tasks done
jonathanknowles opened this issue Jun 29, 2020 · 1 comment
Closed
2 tasks done

Extend pool monitoring code to store retirements in the DB. #1817

jonathanknowles opened this issue Jun 29, 2020 · 1 comment
Assignees
@jonathanknowles
Milestone
(ADP-313) Track S...

Comments

@jonathanknowles
Copy link
Contributor

jonathanknowles commented Jun 29, 2020 •
edited
Loading

Context

As part of the work to track pool retirements, we need to make sure that when the wallet encounters a pool retirement certificate, that the relevant information is recorded in the DB.

Decision

Extend the pool monitoring code to store pool retirements in the DB. Adjust the forward function within monitorStakePools to call putPoolRetirement, along with the corresponding slot and slot internal index.

For a discussion of slot internal indices, see #1815.

Acceptance Criteria

  • The pool monitoring code, on encountering a pool retirement certificate, must ensure that the retirement epoch of that pool is recorded in the DB, along with the slot and slot internal index corresponding to that certificate.

Development

QA

Write integration tests to check that:

  • retiring a pool eventually results in a correct update to the retirement field of ApiStakePool, when read through the ListStakePools operation. (This field is only written as a consequence of the pool monitoring code writing retirements to the DB.)
This was referenced Jun 30, 2020
Closed
Merged
@jonathanknowles jonathanknowles self-assigned this Jul 8, 2020
iohk-bors bot added a commit that referenced this issue Jul 9, 2020
@iohk-bors @jonathanknowles
Merge #1847
c64f0d2 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Issue Number

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the order of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.
- [x] Adds the `RegistrationStatus` type, which indicates the current registration and retirement status of a pool.
    There are _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)
- [x] Adds the `readRegistrationStatus` function to the pool DB layer, making it possible to determine the current `RegistrationStatus` of a pool. 
- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolRegistrationStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolRegistrationStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.
- [x] values of type `SlotInternalId` can be correctly written to and read from the database.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.



Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 9, 2020
@iohk-bors @jonathanknowles
Merge #1847
2835fa8 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Issue Number

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the order of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.
- [x] Adds the `RegistrationStatus` type, which indicates the current registration and retirement status of a pool.
    There are _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)
- [x] Adds the `readRegistrationStatus` function to the pool DB layer, making it possible to determine the current `RegistrationStatus` of a pool. 
- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolRegistrationStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolRegistrationStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.
- [x] values of type `SlotInternalId` can be correctly written to and read from the database.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.



Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 9, 2020
@iohk-bors @jonathanknowles
Merge #1847
8919322 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Issue Number

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the order of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.
- [x] Adds the `RegistrationStatus` type, which indicates the current registration and retirement status of a pool.
    There are _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)
- [x] Adds the `readRegistrationStatus` function to the pool DB layer, making it possible to determine the current `RegistrationStatus` of a pool. 
- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolRegistrationStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolRegistrationStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.
- [x] values of type `SlotInternalId` can be correctly written to and read from the database.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.



Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 9, 2020
@iohk-bors @jonathanknowles
Merge #1847
a27a178 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Issue Number

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the order of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.
- [x] Adds the `RegistrationStatus` type, which indicates the current registration and retirement status of a pool.
    There are _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)
- [x] Adds the `readRegistrationStatus` function to the pool DB layer, making it possible to determine the current `RegistrationStatus` of a pool. 
- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolRegistrationStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolRegistrationStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.
- [x] values of type `SlotInternalId` can be correctly written to and read from the database.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.



Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 9, 2020
@iohk-bors @jonathanknowles
Merge #1847
a5c9e90 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Issue Number

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the order of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.
- [x] Adds the `RegistrationStatus` type, which indicates the current registration and retirement status of a pool.
    There are _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)
- [x] Adds the `readRegistrationStatus` function to the pool DB layer, making it possible to determine the current `RegistrationStatus` of a pool. 
- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolRegistrationStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolRegistrationStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.
- [x] values of type `SlotInternalId` can be correctly written to and read from the database.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.



Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 10, 2020
@iohk-bors @jonathanknowles
Merge #1847
01fbd65 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Related Issues

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the _order_ of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.<br><br>

- [x] Adds the `PoolLifeCycleStatus` type, which indicates the current lifecycle stage of a pool.

    There are currently _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)<br><br>

- [x] Adds the `readPoolLifeCycleStatus` function to the pool DB layer, making it possible to determine the current lifecycle status of a pool. 

- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolLifeCycleStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolLifeCycleStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.

Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 10, 2020
@iohk-bors @jonathanknowles
Merge #1847
07eae29 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Related Issues

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the _order_ of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.<br><br>

- [x] Adds the `PoolLifeCycleStatus` type, which indicates the current lifecycle stage of a pool.

    There are currently _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)<br><br>

- [x] Adds the `readPoolLifeCycleStatus` function to the pool DB layer, making it possible to determine the current lifecycle status of a pool. 

- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolLifeCycleStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolLifeCycleStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.

Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 10, 2020
@iohk-bors @jonathanknowles
Merge #1847
70cea92 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Related Issues

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the _order_ of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.<br><br>

- [x] Adds the `PoolLifeCycleStatus` type, which indicates the current lifecycle stage of a pool.

    There are currently _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)<br><br>

- [x] Adds the `readPoolLifeCycleStatus` function to the pool DB layer, making it possible to determine the current lifecycle status of a pool. 

- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolLifeCycleStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolLifeCycleStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.

Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 10, 2020
@iohk-bors @jonathanknowles
Merge #1847
c1d75e8 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Related Issues

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the _order_ of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.<br><br>

- [x] Adds the `PoolLifeCycleStatus` type, which indicates the current lifecycle stage of a pool.

    There are currently _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)<br><br>

- [x] Adds the `readPoolLifeCycleStatus` function to the pool DB layer, making it possible to determine the current lifecycle status of a pool. 

- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolLifeCycleStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolLifeCycleStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.

Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 10, 2020
@iohk-bors @jonathanknowles
Merge #1847
49e827c 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Related Issues

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the _order_ of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.<br><br>

- [x] Adds the `PoolLifeCycleStatus` type, which indicates the current lifecycle stage of a pool.

    There are currently _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)<br><br>

- [x] Adds the `readPoolLifeCycleStatus` function to the pool DB layer, making it possible to determine the current lifecycle status of a pool. 

- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolLifeCycleStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolLifeCycleStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.

Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 10, 2020
@iohk-bors @jonathanknowles
Merge #1847
bf74a9a 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Related Issues

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the _order_ of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.<br><br>

- [x] Adds the `PoolLifeCycleStatus` type, which indicates the current lifecycle stage of a pool.

    There are currently _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)<br><br>

- [x] Adds the `readPoolLifeCycleStatus` function to the pool DB layer, making it possible to determine the current lifecycle status of a pool. 

- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolLifeCycleStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolLifeCycleStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.

Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 10, 2020
@iohk-bors @jonathanknowles
Merge #1847
88d20a8 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Related Issues

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the _order_ of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.<br><br>

- [x] Adds the `PoolLifeCycleStatus` type, which indicates the current lifecycle stage of a pool.

    There are currently _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)<br><br>

- [x] Adds the `readPoolLifeCycleStatus` function to the pool DB layer, making it possible to determine the current lifecycle status of a pool. 

- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolLifeCycleStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolLifeCycleStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.

Co-authored-by: Jonathan Knowles <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 10, 2020
@iohk-bors @jonathanknowles
@paweljakubas @KtorZ @Anviking
Merge #1847 #1849 #1887
c3eeddc 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Related Issues

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the _order_ of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.<br><br>

- [x] Adds the `PoolLifeCycleStatus` type, which indicates the current lifecycle stage of a pool.

    There are currently _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)<br><br>

- [x] Adds the `readPoolLifeCycleStatus` function to the pool DB layer, making it possible to determine the current lifecycle status of a pool. 

- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolLifeCycleStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolLifeCycleStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.

1849: Diverse witnesses in shelley r=paweljakubas a=paweljakubas

# Issue Number

<!-- Put here a reference to the issue this PR relates to and which requirements it tackles -->
#1844 

# Overview

<!-- Detail in a few bullet points the work accomplished in this PR -->

- [x] I have added WitnessTag
- [x] I have added impl of mkTx for Byron/Icarus wtinesses
- [x] I have added unit tests verifying decodeTx for Byron/Icarus witnesses
- [x] I have updated fee estimation
- [x] I have added integration tests illustrating the case 


# Comments

<!-- Additional comments or screenshots to attach if any -->

 
<!-- 
Don't forget to:

 ✓ Self-review your changes to make sure nothing unexpected slipped through
 ✓ Assign yourself to the PR
 ✓ Assign one or several reviewer(s)
 ✓ Once created, link this PR to its corresponding ticket
 ✓ Assign the PR to a corresponding milestone
 ✓ Acknowledge any changes required to the Wiki
-->


1887: Rename our SlotNo to SlotInEpoch r=Anviking a=Anviking


# Issue Number

#1868
<!-- Put here a reference to the issue this PR relates to and which requirements it tackles -->


# Overview

<!-- Detail in a few bullet points the work accomplished in this PR -->

- [x] Renamed `SlotNo` to `SlotInEpoch` (for consistency with other components)


# Comments

- `W.SlotNo` == `Cardano.SlotInEpoch` /= `Cardano.SlotNo`

```
Epoch       0   1   2   3   4
SlotNo*     0 1 2 3 4 5 6 7 8 9
SlotInEpoch 0 1 0 1 0 1 0 1 0 1
```

*) I.e. the one defined in cardano-base and used in ourobouros-consensus.


<!-- Additional comments or screenshots to attach if any -->

<!-- 
Don't forget to:

 ✓ Self-review your changes to make sure nothing unexpected slipped through
 ✓ Assign yourself to the PR
 ✓ Assign one or several reviewer(s)
 ✓ Once created, link this PR to its corresponding ticket
 ✓ Assign the PR to a corresponding milestone
 ✓ Acknowledge any changes required to the Wiki
-->


Co-authored-by: Jonathan Knowles <[email protected]>
Co-authored-by: Pawel Jakubas <[email protected]>
Co-authored-by: IOHK <[email protected]>
Co-authored-by: KtorZ <[email protected]>
Co-authored-by: Johannes Lund <[email protected]>
iohk-bors bot added a commit that referenced this issue Jul 10, 2020
@iohk-bors @jonathanknowles
Merge #1847
210f392 
1847: Track Stakepool Retirements in the DB r=jonathanknowles a=jonathanknowles

# Related Issues

#1815 
#1816 
#1817 
#1819 
#1880 

# Overview

This PR:

- [x] Extends the pool DB schema to make it possible to store:
    - [x] retirement certificates.
    - [x] the _order_ of publication of certificates _within the same block_, for both registration and retirement certificates. This is necessary, as the intra-block order is _significant_.<br><br>

- [x] Adds the `PoolLifeCycleStatus` type, which indicates the current lifecycle stage of a pool.

    There are currently _three_ possibilities:
    1. `NotRegistered`
        (indicates that a pool has never been registered)
    2. `Registered`
        (indicates that a pool has been registered but _not_ retired)
        (provides a registration certificate)
    3. `RegisteredAndRetired`
        (indicates that a pool has been registered _and_ retired)
        (provides both a registration and a retirement certificate)<br><br>

- [x] Adds the `readPoolLifeCycleStatus` function to the pool DB layer, making it possible to determine the current lifecycle status of a pool. 

- [x] Updates the `retirement` field of `ApiStakePool` with live information.

# Property Tests

This PR adds property tests to ensure that:

- [x] the `determinePoolLifeCycleStatus` function respects the correct order of precedence for registration and retirement certificates:
    - for a given pool, a registration certificate always _supercedes_ a prior retirement certificate.
    - for a given pool, a retirement certificate always _augments_ the latest registration certificate.
- [x] `readPoolLifeCycleStatus` queries work correctly in the presence of blocks containing multiple certificates for the same pool.
- [x] database rollback works correctly in the presence of retirement certificates.

# Future Work

A **_future_** PR will add integration tests to ensure that:

- retiring a pool eventually results in a correct update to the `retirement` field of `ApiStakePool`, when read through the `ListStakePools` operation.
- retiring and then re-registering a pool clears the `retirement` field. 

See QA section of #1819.

Co-authored-by: Jonathan Knowles <[email protected]>
@piotr-iohk
Copy link
Contributor

lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@jonathanknowles jonathanknowles

Labels
None yet
Projects
None yet
Milestone
(ADP-313) Track Stakepool Retirements
Development

No branches or pull requests
2 participants
@jonathanknowles @piotr-iohk