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

Track stake key registrations independently from delegation #1851

Merged
merged 10 commits into from
Jul 3, 2020

Conversation

Anviking
Copy link
Collaborator

@Anviking Anviking commented Jul 3, 2020

Issue Number

#1835

Overview

  • Keep track of stake key registrations such that we don't try to register a key twice
  • TODO: model impl
  • There was a integration test, which I saw passing at some point, but I've not rebased it to this PR
  • Some DB model-like tests would have been nice, but no time now

Comments

To delegate in shelley we need to know whether we need to register the
stake key, or if it already exists. Trying to register the same key
twice will cause the delegation to fail.

In shelley there are three delegation certs:

  • reg
  • dereg
  • delegate

We need to keep track of two things:

  • Delegation status
  • Is the stake key registered or not? (new in this commit)

Also new in this commit:

  • Stake key de-registration inserts an uptdate to the delegation status
    table that says that it is not delegating.

@Anviking Anviking self-assigned this Jul 3, 2020
@KtorZ KtorZ self-requested a review July 3, 2020 18:21
@KtorZ KtorZ added the IMPROVEMENT Mark a PR as an improvement, for auto-generated CHANGELOG label Jul 3, 2020
(DelegationCertificate wid sl Nothing)
pure <$> repsert
(StakeKeyCertificateKey wid sl)
(StakeKeyCertificate wid sl False)
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Here we insert "deregistration" into both tables

@KtorZ
Copy link
Member

KtorZ commented Jul 3, 2020

Stake key de-registration inserts an uptdate to the delegation status
table that says that it is not delegating.

This seems wrong. Stake key de-registration should be tracked separately as well, and the delegation status should be inferred from the database current status (as it is now).

@Anviking Anviking added RESOLVING ISSUE Mark a PR as resolving issues, for auto-generated CHANGELOG and removed IMPROVEMENT Mark a PR as an improvement, for auto-generated CHANGELOG labels Jul 3, 2020
StakeKeyCertificate
stakeKeyCertWalletId W.WalletId sql=wallet_id
stakeKeyCertSlot W.SlotId sql=slot
stakeKeyCertIsReg Bool sql=is_reg
Copy link
Member

Choose a reason for hiding this comment

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

I'd recommend using something more explicit than a boolean here. Boolean convey very little information and they are easy to misinterpret (like I did on my first review...). I'd suggest something like Registration | Deregistration, stored as plain text lowercased in the database, so it's also readable when debugging / inspecting.

[Desc StakeKeyCertSlot]

return $ case val of
Nothing -> Left $ ErrNoSuchWallet wid
Copy link
Member

Choose a reason for hiding this comment

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

Hmmm. No. There could be a wallet but no key. This should return negatively about the existing of a key, but not return an error. To know whether there's a wallet, this should use the same pattern as for other functions:

            selectWallet wid >>= \case
                Nothing -> pure $ Left $ ErrNoSuchWallet wid
                Just{} -> {- ... do actual stuff ... -}

stakeKeyCertSlot W.SlotId sql=slot
stakeKeyCertIsReg Bool sql=is_reg

Primary stakeKeyCertWalletId stakeKeyCertSlot
Copy link
Member

Choose a reason for hiding this comment

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

👍

@@ -676,7 +676,8 @@ fromShelleyDelegationCert = \case
SL.DCertDeleg (SL.DeRegKey credentials) ->
Just $ W.CertDelegateNone (fromStakeCredential credentials)

SL.DCertDeleg SL.RegKey{} -> Nothing
SL.DCertDeleg (SL.RegKey cred) ->
Just $ W.CertRegisterKey $ fromStakeCredential cred
Copy link
Member

Choose a reason for hiding this comment

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

👍

[Desc StakeKeyCertSlot]
return $ case val of
Nothing -> Right False
Just (StakeKeyCertificate _ _ isReg) -> Right isReg
Copy link
Member

Choose a reason for hiding this comment

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

👍

Anviking and others added 3 commits July 3, 2020 22:09
To delegate in shelley we need to know whether we need to register the
stake key, or if it already exists. Trying to register the same key
twice will cause the delegation to fail.

In shelley there are three delegation certs:
- reg
- dereg
- delegate

We need to keep track of two things:
- Delegation status
- Is the stake key registered or not? (new in this commit)

Also new in this commit:
- Stake key de-registration inserts an uptdate to the delegation status
table that says that it is not delegating.
Booleans are error-prone and convey very little information without
surrounding context. A sum-type is cheap and much easier to read and
debug (even in the database!).

Co-authored-by: KtorZ <matthias.benkort@iohk.io>
@KtorZ KtorZ force-pushed the anviking/1835/track-key-certs branch from 1d3aa95 to 68fbe3b Compare July 3, 2020 20:34
@KtorZ KtorZ force-pushed the anviking/1835/track-key-certs branch from 68fbe3b to 8a33b1e Compare July 3, 2020 20:41
to allow tests to call it
STAKE_POOLS_JOIN_05

This is a regression test for
"Cannot join pool with ITN rewards wallet on shelley testnet"
"passphrase": "Secure Passphrase"
} |]

threadDelay 4000000
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Should use eventually I guess


-- | Pre-register a staking key for the STAKE_POOLS_JOIN_05 test.
preregisterStakingKeysForTests :: NetworkLayer IO t b -> IO ()
preregisterStakingKeysForTests nl = do
Copy link
Member

Choose a reason for hiding this comment

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

I am not fond of having this function here but I guess it'll do for now. Ideally, I'd have put that where the rest of the "setup & fixture" work is happening (i.e. in the "Launch" module).

, outputs = []
, change = []
, deposit = 100000 -- keyDeposit
}
Copy link
Member

Choose a reason for hiding this comment

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

CoinSelection is a Monoid, so you can write instead:

mempty { inputs = [(txIn, dummyOut)], deposit = 100000 }

Also, note that the key deposit is available in protocol parameters, would be better than hard-coding it.

Copy link
Collaborator Author

@Anviking Anviking Jul 3, 2020

Choose a reason for hiding this comment

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

key deposit is available in protocol parameters

👍

CoinSelection is a Monoid

Didn't think about it, but in this case I found it useful to explicitly see the new fields of CoinSelection.

data StakeKeyCertificate
= StakeKeyRegistration
| StakeKeyDeregistration
deriving (Generic, Show, Read, Eq)
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

There are so many different kinds of certificate types in here already, for multiple purposes. I'd preferred to keep it closer to the DB.

"passphrase": "Secure Passphrase"
} |]

threadDelay 4000000
Copy link
Member

Choose a reason for hiding this comment

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

Why the delay?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We try to join immediately when the wallet is created. It has no time to find the existing key reg cert.

Should probably use eventually though. Just sprinkled it in to get it passing.

So that we don't get to look at so many places when trying to figure out how the test cluster is setup. It's also using the cardano-cli for consistency with other fixtures (and because we have nice logging and retrying in place for this in the module already).
Copy link
Member

@KtorZ KtorZ left a comment

Choose a reason for hiding this comment

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

Reviewed, partially fixed and partially extended.

@KtorZ
Copy link
Member

KtorZ commented Jul 3, 2020

bors r+

iohk-bors bot added a commit that referenced this pull request Jul 3, 2020
1851: Track stake key registrations independently from delegation r=KtorZ a=Anviking

# Issue Number

#1835 


# Overview


- [x] Keep track of stake key registrations such that we don't try to register a key twice
- [ ] TODO: model impl
- There was a integration test, which I saw passing at some point, but I've not rebased it to this PR
- Some DB model-like tests would have been nice, but no time now

# Comments

To delegate in shelley we need to know whether we need to register the
stake key, or if it already exists. Trying to register the same key
twice will cause the delegation to fail.

In shelley there are three delegation certs:
- reg
- dereg
- delegate

We need to keep track of two things:
- Delegation status
- Is the stake key registered or not? (new in this commit)

Also new in this commit:
- Stake key de-registration inserts an uptdate to the delegation status
table that says that it is not delegating.

<!-- 
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: Johannes Lund <johannes.lund@iohk.io>
Co-authored-by: KtorZ <matthias.benkort@gmail.com>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Jul 3, 2020

Canceled

@KtorZ
Copy link
Member

KtorZ commented Jul 3, 2020

bors r+

iohk-bors bot added a commit that referenced this pull request Jul 3, 2020
1851: Track stake key registrations independently from delegation r=KtorZ a=Anviking

# Issue Number

#1835 


# Overview


- [x] Keep track of stake key registrations such that we don't try to register a key twice
- [ ] TODO: model impl
- There was a integration test, which I saw passing at some point, but I've not rebased it to this PR
- Some DB model-like tests would have been nice, but no time now

# Comments

To delegate in shelley we need to know whether we need to register the
stake key, or if it already exists. Trying to register the same key
twice will cause the delegation to fail.

In shelley there are three delegation certs:
- reg
- dereg
- delegate

We need to keep track of two things:
- Delegation status
- Is the stake key registered or not? (new in this commit)

Also new in this commit:
- Stake key de-registration inserts an uptdate to the delegation status
table that says that it is not delegating.

<!-- 
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: Johannes Lund <johannes.lund@iohk.io>
Co-authored-by: KtorZ <matthias.benkort@gmail.com>
These tests are quite flaky and often failing for no reason. Plus, they are testing things at the integration level since they require a running node and they are redundant with other integration scenario that are ran as part of the integration test suite
@KtorZ KtorZ force-pushed the anviking/1835/track-key-certs branch from 734604d to fc77374 Compare July 3, 2020 22:50
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Jul 3, 2020

Canceled

@KtorZ
Copy link
Member

KtorZ commented Jul 3, 2020

bors r+

iohk-bors bot added a commit that referenced this pull request Jul 3, 2020
1851: Track stake key registrations independently from delegation r=KtorZ a=Anviking

# Issue Number

#1835 


# Overview


- [x] Keep track of stake key registrations such that we don't try to register a key twice
- [ ] TODO: model impl
- There was a integration test, which I saw passing at some point, but I've not rebased it to this PR
- Some DB model-like tests would have been nice, but no time now

# Comments

To delegate in shelley we need to know whether we need to register the
stake key, or if it already exists. Trying to register the same key
twice will cause the delegation to fail.

In shelley there are three delegation certs:
- reg
- dereg
- delegate

We need to keep track of two things:
- Delegation status
- Is the stake key registered or not? (new in this commit)

Also new in this commit:
- Stake key de-registration inserts an uptdate to the delegation status
table that says that it is not delegating.

<!-- 
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: Johannes Lund <johannes.lund@iohk.io>
Co-authored-by: KtorZ <matthias.benkort@gmail.com>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Jul 3, 2020

Canceled

@KtorZ
Copy link
Member

KtorZ commented Jul 3, 2020

bors r+

@iohk-bors
Copy link
Contributor

iohk-bors bot commented Jul 3, 2020

@iohk-bors iohk-bors bot merged commit cc9b576 into master Jul 3, 2020
@iohk-bors iohk-bors bot deleted the anviking/1835/track-key-certs branch July 3, 2020 23:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RESOLVING ISSUE Mark a PR as resolving issues, for auto-generated CHANGELOG
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants