-
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
Add api swagger spec for shelley stake pools #1744
Conversation
specifications/api/swagger.yaml
Outdated
produced_blocks: | ||
<<: *numberOfBlocks | ||
description: Number of blocks produced by a given stake pool. | ||
apparent_performance: *stakePoolApparentPerformance |
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.
Do we actually still have this one on cardano-node ?
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.
Are we going to display some form of produced_blocks
? Then why not? Though it will be a different apparent performance from that used to calculate the non-myopic 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.
We also need the pool's stake on the previous epoch, do we have that?
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 LSQ worked for k blocks old, then we have stake distributions for the k latest blocks.
Should we remove?
Should we not also remove produced_blocks
? (Or have say lifetime_blocks
if we keep it?)
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.
Ideally we would have both last production and total production. Though we do not depend on the LSQ for these, we have this information from the chain sync data.
I'm not sure. If LSQ worked for k blocks old, then we have stake distributions for the k latest blocks. Should we remove?
Well, without the stake distribution of past epochs, we are running into the same problem / awkwardness as during the ITN where we would have holes in our dataset. I'd rather not go through this again.
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.
Well, without the stake distribution of past epochs, we are running into the same problem / awkwardness as during the ITN where we would have holes in our dataset. I'd rather not go through this again.
To be fair: We are guaranteed to have k
blocks with corresponding stake distributions (except for at genesis). On the ITN we weren't guaranteed to have that.
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.
What would the point of last_production
be, and what would the window be? Wouldn't it just be to give users some notion of the apparent performance?
Then why not either remove both last_production
and apparent_performance
, or keep both? 🤔
ab13993
to
cedcba9
Compare
specifications/api/swagger.yaml
Outdated
x-non-myopic-member-rewards: &nonMyopicMemberRewards | ||
<<: *amount | ||
description: | | ||
Non-myopic member rewards is the recomended way to rank stake pools. It is the rewards the |
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.
Perhaps this is a weird way to describe it.
E.g. for what unit of time do the rewards correspond to? (I think it is an epoch.)
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.
Non-myopic member rewards = rewards one can expect at the end of an epoch from a fully saturated pool.
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 rephrased in 44e6ff8
epoch from a fully saturated pool
That is misleading though? It is assuming the top k pools are saturated, and the rest are empty (except the user's stake… and pledge?), or something like that. I didn't mention on those specifics in the commit.
1e27e7e
to
8ac875f
Compare
9c249fb
to
a42e9ae
Compare
e73a779
to
78ab757
Compare
d42dd19
to
46c04c9
Compare
specifications/api/swagger.yaml
Outdated
The rewards the wallet can expect to receive at the end of an epoch, in the long term, if delegating to | ||
this pool. | ||
|
||
For more details, see the "Design Specification for Delegation and Incentives in Cardano" document. |
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.
We could link it here (the description is actually plain markdown)
specifications/api/swagger.yaml
Outdated
|
||
Some pools _may_ also have metadata attached to them. | ||
|
||
The `non_myopic_member_rewards` — and thus the ordering — depends on the balance of the given wallet. |
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.
Small note, I'd actually swap these two sentences. So that it we give precision on the ordering after actually mentioning that pools are ordered by descending 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.
List all known stake pools ordered by descending non_myopic_member_rewards
. The non_myopic_member_rewards
— and thus the ordering — depends on the balance of the given wallet.
/!\ On the incentivized testnet, pools are instead ordered by descending
desirability
.
Some pools may also have metadata attached to them.
specifications/api/swagger.yaml
Outdated
produced_blocks: | ||
<<: *numberOfBlocks | ||
description: Number of blocks produced by a given stake pool | ||
apparent_performance: *stakePoolApparentPerformance |
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.
Let's remove that one as discussed.
bors r+ |
1744: Add api swagger spec for shelley stake pools r=Anviking a=Anviking # Issue Number #1718 # Overview <!-- Detail in a few bullet points the work accomplished in this PR --> - [x] Added swagger spec for shelley pools - [x]⚠️ Breaking: Make both the haskell and jormungadnr API require a wallet id to list stake pools # 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 --> Co-authored-by: Johannes Lund <[email protected]>
Build 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.
LGTM!
9529c4f
to
282785f
Compare
-- that differs, such that we validate both. | ||
type CustomApi n = | ||
Api n ApiStakePool | ||
:<|> ("jormungandr" :> StakePools n ApiJormungandrStakePool) |
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.
@KtorZ I hope you don't mind this
bors try |
tryBuild failed |
a63516f
to
cd63108
Compare
And make listing stake pools require a wallet: Old: GET /stake-pools New: GET /wallets/{id}/stake-pools And parameterise the full API type over apiPool. The current jormungandr specific types and schemas were renamed appropriately, e.g: ApiStakePoolMetrics -> ApiJormungandrStakePoolMetrics
cd63108
to
5022e3f
Compare
bors r+ |
Build succeeded |
Issue Number
#1718
Overview
apiPool
Comments