-
Notifications
You must be signed in to change notification settings - Fork 217
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
List stake pools #1753
List stake pools #1753
Conversation
d9ebdfe
to
a63516f
Compare
9b25d56
to
a9064eb
Compare
a63516f
to
cd63108
Compare
a9064eb
to
356e55a
Compare
cd63108
to
5022e3f
Compare
356e55a
to
8b900d8
Compare
5259ebf
to
85e2c05
Compare
85e2c05
to
ebca9b7
Compare
bors try |
tryBuild failed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if you would like a review yet, but I see that you are using the Cursor
fields to access the lsqQ
. Perhaps we would just need another NetworkLayer
method for this. Because for Jormungandr, we needed to track pools, but for cardano-node, we can simply query.
The
We are still going to track pool registration certificates. It could perhaps be useful to allow the LSQ to fetch metrics from the chain-follower tip, instead of the NetworkLayer's currentNodeTip, to guarantee consistency — but just a guess. |
I don't think this is generally possible. The LSQ has only a certain history of the past. It'd be nice if we could move the chain sync cursor forward, fetch some ledger state data, move forward, and so forth. |
To allow both PParams, and StakeDistribution checks in the same queue.
ebca9b7
to
b776da2
Compare
- Return dummy rewards, cost, margin, productions for now - Embed LSQ queue in cursor - Remove mock knownPools
b776da2
to
31c7cb5
Compare
Map.merge stakeButNoRew rewardsButNoStake bothPresent | ||
where | ||
-- calculate the saturation from the relative stake | ||
sat s = fromRational $ (getPercentage s) / (1 / fromIntegral nOpt) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
-> Map PoolId (Quantity "lovelace" Word64) | ||
-> Map PoolId PoolLsqMetrics | ||
combine nOpt = | ||
Map.merge stakeButNoRew rewardsButNoStake bothPresent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is it actually possible with the LSQ to have cases where a poolId wouldn't be in both maps? From the excerpt above, I get that these are two separate requests, but the local state query allows for "locking" a state and making several queries on that locked state if I recall correctly? So in principle, that's sort of a guarantee that the list of pools fetched from the stake distribution is exactly the same as the list of pools get from the member rewards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The poolId may not be in the rewards map (clarified comment in cacff55)
As for the rewardsButNoStake
case: I suspect that is impossible. (Maybe @rvl knows for sure though?)
I guess we should have some InconcistentMetrics
similar to what we had for jormungandr, instead of the current silent dropMissing
.
We will have more problems like this when we start folding over pool registration certificates on the chain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I suspect that is impossible
But I guess regardless of locking or not, we are making the queries with the same specific Point
, so they should all be consistent if they succeed 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we should have some InconcistentMetrics similar to what we had for jormungandr, instead of the current silent dropMissing.
Not really though. In the case of Jörmungandr, we knew we could end up with inconsistent metrics because of the concurrent nature of our logic + the stateless API from Jörmungandr. So it was kind of expected. With cardano-node here, this is really something we do not expect, and therefore,not something we're willing to push onto the caller of this function.
…for failure) Also, now passing around spl instead of a separate server for the list stake pool endpoint.
Using a type family to allow jormungandr and haskell implementations to be different.
95a8af8
to
4ba37cf
Compare
stake <- withWorkerCtx shelley wid liftE liftE $ \wrk -> do | ||
(w, _, pending) <- liftHandler $ W.readWallet wrk wid | ||
return $ Coin $ fromIntegral $ totalBalance pending w | ||
liftHandler $ listStakePools spl stake |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should eventually include the reward balance as well.
rewardsPerAccount <- fromNonMyopicMemberRewards <$> handleQueryFailure | ||
(queue `send` CmdQueryLocalState pt (OC.GetNonMyopicMemberRewards toStake)) | ||
pparams <- handleQueryFailure | ||
(queue `send` CmdQueryLocalState pt OC.GetCurrentPParams) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one feels quite redundant / awkward. It sure is needed by the caller to compute few things on the pool data, but the caller should simply call getProtocolParameters
, don't you think ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code guarantees that the pparams
are valid at the same point pt
.
If we were to instead use
getProtocolParameters :: m ProtocolParameters
We lose that control, and introduce potential race conditions. Even if unlikely, that feels incredibly wrong to me.
-- Temporary | ||
|
||
notImplemented :: HasCallStack => String -> a | ||
notImplemented what = error ("Not implemented: " <> what) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
{ nonMyopicMemberRewards = Quantity 0 | ||
, relativeStake = s | ||
, saturation = (sat s) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't the spec suggests something about this? Should we order pool randomly in that case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought that was when we don't have enough data.
I would think that ranking according to the rewards if the user had money, would be a better thing to do.
A user can't delegate without any money anyway.
We could include ROI in % and return null
for the non-myopic member rewards.
_knownPools = do | ||
pt <- getTip | ||
res <- runExceptT $ map fst . Map.toList | ||
. combineLsqData <$> stakeDistribution nl pt dummyCoin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't use the network layer but use the database. Yet, you'll need the work on my branch for that. I'll modify this function in there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Though why?
I know knownPools
are used to validate the users's choice of delegation.
The pool worker is less likely to be in sync with the network (more downstream) than the node.
Wouldn't implementing it in terms of the LSQ make more sense?
bors try |
@@ -163,7 +169,8 @@ data StakePoolLayer e m = StakePoolLayer | |||
-- The pool productions and stake distrubtions in the db can /never/ be from | |||
-- different forks such that it's safe for readers to access it. | |||
monitorStakePools | |||
:: Tracer IO StakePoolLog | |||
:: GetStakeDistribution t IO ~ GetStakeDistribution Jormungandr IO |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason for not writing:
:: GetStakeDistribution Jormungandr IO
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - allowing other targets than Jormungandr
in the tests :S https://github.com/input-output-hk/cardano-wallet/blob/1fab8e511360af8e567a6f2fd4e9e7b77c3df917/lib/jormungandr/test/unit/Cardano/Pool/Jormungandr/MetricsSpec.hs#L278-L281
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking we should get rid of the NetworkLayer
(or break it up) later and the need for the type families (and this weirdness)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, this is required for module Cardano.Pool.Jormungandr.MetricsSpec
and the polymorphism on the target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am thinking we should get rid of the NetworkLayer (or break it up) later and the need for the type families (and this weirdness)
Although the source of the problem isn't much the NetworkLayer
here, but the double-support Jormungandr / cardano-node 🙃
Another abstraction could work better, but it'd still have to deal with backend discrepancies.
tryTimed out |
Issue Number
#1718, #1720
Overview
Comments
Actually fetching non-myopic member rewards depends on a consensus change reaching cardano-node.
Working chain following may be a non-goal for this PR, but trying to make room for it.