Merge update-confirmation and adoption thresholds #623
Labels
Milestone
Comments
dnadales
added a commit
that referenced
this issue
Aug 1, 2019
…nst the implementation in `cardano-ledger`. - Fix the implementation of `PVBUMP`: the last proposal was being taken instead of the first one. - Simplify the `EPOCH` rule. - Count the block endorsement when registering it. - Remove `cfmThd` use `upAdptThd` instead, since these are the same value, and we have no compelling reasons for using different ones here. This closes #623 - Perform application version change, even when there are not votes in the block. - Generate the update id's based on the `pwd` set (otherwise we would be generating duplicated proposal id's). - Add a constant `c` to `GlobalParams` which is used to bound the concrete size. We use this constant when choosing the next `B` factor, and when elaborating this factor into a concrete one.
dnadales
added a commit
that referenced
this issue
Aug 1, 2019
Fix errors discovered during conformance testing of valid chains against the implementation in `cardano-ledger`. - Fix the implementation of `PVBUMP`: the last proposal was being taken instead of the first one. - Simplify the `EPOCH` rule. - Count the block endorsement when registering it. - Remove `cfmThd` use `upAdptThd` instead, since these are the same value, and we have no compelling reasons for using different ones here. This closes #623 - Perform application version change, even when there are not votes in the block. - Generate the update id's based on the `pwd` set (otherwise we would be generating duplicated proposal id's). - Add a constant `c` to `GlobalParams` which is used to bound the concrete size. We use this constant when choosing the next `B` factor, and when elaborating this factor into a concrete one.
kevinhammond
pushed a commit
that referenced
this issue
Oct 28, 2019
Fix errors discovered during conformance testing of valid chains against the implementation in `cardano-ledger`. - Fix the implementation of `PVBUMP`: the last proposal was being taken instead of the first one. - Simplify the `EPOCH` rule. - Count the block endorsement when registering it. - Remove `cfmThd` use `upAdptThd` instead, since these are the same value, and we have no compelling reasons for using different ones here. This closes #623 - Perform application version change, even when there are not votes in the block. - Generate the update id's based on the `pwd` set (otherwise we would be generating duplicated proposal id's). - Add a constant `c` to `GlobalParams` which is used to bound the concrete size. We use this constant when choosing the next `B` factor, and when elaborating this factor into a concrete one.
nc6
pushed a commit
that referenced
this issue
May 19, 2020
623: Modify the MempoolPayload data type r=intricate a=intricate When originally implementing #514 (PR #554), I wasn't _exactly_ aware of how this `MempoolPayload` data type was going to be used and I defined it incorrectly. The mempool needs to be able to hold _individual_ ledger objects (transactions, delegation certs, update proposals, and update votes) while the `*Payload` data types I originally utilized hold collections of the aforementioned objects. Co-authored-by: Luke Nadur <19835357+intricate@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We can have a single threshold to be used for confirmation and adoption.
Having this reduces the space of possibilities we need to test, and
simplifies the update mechanism further.
The text was updated successfully, but these errors were encountered: