-
Notifications
You must be signed in to change notification settings - Fork 160
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
Ambit claim for ledger event rewards #1080
base: master
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||
---|---|---|---|---|---|---|
@@ -0,0 +1,47 @@ | ||||||
# Ledger Reward Events | ||||||
|
||||||
This is an ambit claim of what data the ledger events should provide from the point of view of | ||||||
`db-sync`. | ||||||
|
||||||
## Prologue | ||||||
|
||||||
In the context of `db-sync` and the `ledger`, the word "reward" is slightly misleading and should | ||||||
not be narrowly defined as only being payments of staking rewards, but defined much more broadly as | ||||||
any and all payments to a stake address. None of these payments are recorded on the block chain as | ||||||
part of regular transactions. | ||||||
|
||||||
Payments to stake addresses are made for one of following reasons: | ||||||
* Staking rewards for being a member of a stake pool. | ||||||
* Staking rewards for being an owner of a stake pool. | ||||||
* MIR payments from the treasury. | ||||||
* MIR payments from the reserves. | ||||||
* Refunds of the stake pool deposit payment when a pool is de-registered. | ||||||
|
||||||
Currently, the ledger provides the following reward related events: | ||||||
* `LEDeltaReward` | ||||||
* `LEMirTransfer` | ||||||
* `LERetiredPools` | ||||||
* `LETotalRewards` | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||
|
||||||
These events are currently only used by `db-sync` but it is my understanding that in the future, | ||||||
other programs will also start using these. | ||||||
|
||||||
|
||||||
## The Desired Ledger Event Functionality | ||||||
|
||||||
* Every event should carry an `EpochNo` field to make debugging and validation on the `db-sync` side | ||||||
easier. | ||||||
* A single `LETotalRewards` event should be emitted for every epoch in the Shelley era and later, | ||||||
even if there are no rewards for that epoch (in which case the event reward map will be `mempty`). | ||||||
* `LETotalRewards` should include all payments to stake addresses for a given epoch. That means | ||||||
all staking rewards (member and owner), all MIR payments and all stake pool deposit refunds. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is currently no such There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Is there any accomodation There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
oh! Where does
Absolutely! We just can't glue these events together in the way you are proposing, not with serious consequences |
||||||
* `LEDeltaReward` should only ever contain pool membership or pool ownership rewards. | ||||||
* `LEDeltaReward` may contain rewards to stake addresses that have been de-registered. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here are some extra details that might be helpful. In the Alonzo era, and previous eras:
In the Babbage era:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Era specific behavior for any event is a huge pain in the neck for |
||||||
* The sum of all `LEDeltaReward`, `LEMirTransfer` and `LERetiredPools` amounts for an epoch should | ||||||
always be the same as the sum of `LETotalRewards` event amounts for that epoch. | ||||||
* `LETotalRewards` will not contain rewards to stake addresses that have been de-registered. | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This requirement (that the total reward event sum is equal to the sum of the other events) is inconsistent with the idea that the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 😢 Do we have a different idea of the meaning of the word "total"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
These three requirements are inconsistent. A reward for a stake addresses that has been de-registered would be in the sum of "all |
||||||
* The `LETotalRewards` must be the last reward related event for a given epoch to be emitted from | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The ledger will make no guarantees about the ordering of the events corresponding to a given block. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So I can theoretically get an There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes that is theoretically possible. The event is still useful, we use it in the ledger property tests to ensure that the delta rewards are what we expect. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The goal of all of these events is to be used by |
||||||
the ledger. | ||||||
* For the Shelley Era (ie after Byron and before Mary), for the `LETotalRewards` event, all staking | ||||||
addresses should only contain one staking reward amount (if an address receives both an ownership | ||||||
and a membership reward, the later will be dropped). |
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.
It's probably worth noting that the list below is the name of the wrapped events from the Cardano API. The corresponding ledger events are currently nested according to the ledger rule hierarchy (though we may change this is the near future, a clean up is on order)
ShelleyLedgerEventTICK . NewEpochEvent . DeltaRewardEvent . RupdEvent
ShelleyLedgerEventTICK . NewEpochEvent . MirEvent
ShelleyLedgerEventTICK . NewEpochEvent . EpochEvent . PoolReapEvent
ShelleyLedgerEventTICK . NewEpochEvent . TotalRewardEvent