CPS-0006? | Governance Security #491
Conversation
This is the initial commit for the governance security CIP based on discussions at the Longmont Voltaire CIP-1694 Working Group.
correct the format for spacing
Added the correct authors
Posted the pull request discussion link to the discussion section of the header.
Correct typos in the abstract Co-authored-by: Adam Dean <63186174+Crypto2099@users.noreply.github.com>
Added threat number 1 to the Specification section to begin the process.
Added an initial list of governance threats for public review, comment, input, and feedback.
Brackets not needed. N/A until responses are received. Co-authored-by: Adam Dean <63186174+Crypto2099@users.noreply.github.com>
better description Co-authored-by: Adam Dean <63186174+Crypto2099@users.noreply.github.com>
spelling errors Co-authored-by: Jane14457995 <90640701+Jane14457995@users.noreply.github.com>
CPS is the correct category Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
All sections need to be demoted to H2 Co-authored-by: Robert Phair <rphair@cosd.com>
Change specification to goals and demote to H2 Co-authored-by: Robert Phair <rphair@cosd.com>
Improved description the CPS intent Co-authored-by: Shaneeljiv <49743809+Shaneeljiv@users.noreply.github.com>
Co-authored-by: CIP-review <129207554+CIP-review@users.noreply.github.com>
Batch of multiple typo corrections Co-authored-by: jungmyeonghan <55140432+jungmyeong96@users.noreply.github.com> Co-authored-by: CIP-review <129207554+CIP-review@users.noreply.github.com>
Demoted remaining sections to H2
Motivation to H2
This is the initial commit for the Governance Security CPS. It includes the previous edits from the first pull request in CIP format. This document has been reformatted to the CPS template style.
Added new link to discussions for this CPS pull request and kept the original CIP pull request link.
| ### #16: Risk of Proposal overload - Risk of DDOS. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
-
Require collateral to accompany a proposal (i.e. 50 $Ada or higher)
-
Collateral reimbursement once proposal is approved for a voting round or rejected due to constitutional violation
There was a problem hiding this comment.
Same as above, I think we need to define the difference between a deposit and collateral, and which entity would have the power to slash it. Also might need to consult the game theory experts on slashing mechanisms as a form of punishment.
| -overlapping actions and duplicate actions | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
- Intentional attempts to submit parameter change proposals that are deemed detrimental to the health of the network should result in a loss of collateral. As mentioned for line 118, collateral should be required to submit proposals.
- Overlapping/duplicate actions should be mostly curbed due to collateral requirement. If 1:1 duplicate is successfully proposed, the enforcement of a penalty from collateral as a percentage might be appropriate.
There was a problem hiding this comment.
Not sure there is a risk here. We would need all governing bodies to agree that the submitted proposal is 1) valid and 2) everyone votes to pass it.
| Education of correct procedures for DReps | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
Curriculum framed from the contents of the constitution and the approved governance CIP (CIP-1694 or otherwise)
| ### #19: Sybil behavior - one person acting as multiple DReps. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
Loss of collateral and expungement of registration. DReps should also be required to submit collateral with their registration. Not dissimilar from a minimum pledge with a stake pool.
There was a problem hiding this comment.
same as above, if there is a difference between collateral and deposit.
There was a problem hiding this comment.
If the voting power is based on total ADA behind the DRep then what point would there be to create multiple registrations? To bloat the the chain? You could argue the transaction cost to register as a DRep would make this unattractive in the same way spamming the network with tiny transactions prevents DDoS
|
|
||
| ### #21: Superstar attack - one “superstar” person that everybody delegates to becomes a dictator with little skin in the game. | ||
| (Example: Elon Musk as a DRep) | ||
|
|
There was a problem hiding this comment.
Collateral exceptions or tiers - A potential process during DRep registration where an approval/finalization process occurs by committee. A tiered collateral model might be appropriate, levied based on certain criteria (i.e. social influence, history of nefarious behavior)
There was a problem hiding this comment.
Must be solved in the constitution (separation of powers again)
| ### #6: DRep keys lost or stolen or DRep keys sold to a bad actor. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
-
Lost/Stolen : DRep must be able to sign with the same wallet/stake key to authenticate for burn/mint of previous key
-
Sold to bad actor : Loss of collateral / Keys destroyed by committee vote
There was a problem hiding this comment.
I think the corrective action for lost, stolen, or sold is the same. The keys must be burned and new ones generated. Same as above. I think the difference in how new keys are generated is in the implementation.
| ### #5: Committee keys lost or stolen or committee keys sold to a bad actor. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
-
Lost/Stolen : Member must be able to sign with the same wallet/stake key to authenticate for burn/mint of previous key
-
Sold to bad actor : Loss of collateral / Keys destroyed by committee vote
There was a problem hiding this comment.
I think the result of lost, stolen, or sold is the same. The keys must be burned and new ones generated. I could be wrong.
There was a problem hiding this comment.
Yup, same. Lost, stolen, or suspected of compromise
| ### #11: Collusion - the bad version of collaboration to do something illegal or undesirable. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
If this is collusion on the part of any committees members or DReps, it should result in loss of collateral by committee vote. Evidence needs to be presented in a reasonable and articulable way to a body (i.e. Oversight & Accountability Committee), with specific constitutional citations that explains the behavior and/or actions. Voting on such an action must be constitutionally based, not emotionally based.
There was a problem hiding this comment.
I don't know if the deposit to be a DRep can be revoked by any other entity. This could work. Will tag @JaredCorduan and @KtorZ to ask if this is technically possible or would require a code change?
There was a problem hiding this comment.
as currently written, no, there is no way to revoke the deposit.
I'm personally not a fan of giving the CC this new power, which could in theory could be abused.
There was a problem hiding this comment.
I agree that the CC should have no powers beyond what is currently described in CIP-1694. I suppose I am envisioning a separate body to provide some oversight with issues like these.
There was a problem hiding this comment.
What about revoking a key's ability to vote/propose changes? Not sure how feasible it would be to maintain a naughty list.
That being said... what's the difference between collusion to do something bad/undesirable vs something good/desirable? (legal/illegal is globally as subjective as good and bad). This feels like something that must be managed by CIP1964 and the constitution.
| ### #15: Persistence - Removal of proposals by attackers. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
I know I continue to suggest collateral. I'm going to do it here, too. If an individual or group of individuals want to remove a proposal, collateral should be required, just as submitting the proposal should. If the removal request is found by committee to be nefarious and/or without merit, a loss of collateral should occur.
There was a problem hiding this comment.
Same as above, I don't know if the deposit by the DRep is considered a collateral, or a deposit that can be only returned to the depositer. For example no other keyholder can revoke a stake pool deposit of 500 Ada. Only the keyholder can do it afaik.
There was a problem hiding this comment.
I agree, collateral should be required.
There was a problem hiding this comment.
Hey @rickymac68, thanks for changing this to a CPS and addressing the immediate comments.
This CPS format is still young and may not exactly match, but I believe this is a better fit than a CIP. See my suggestions on structure and formatting throughout.
CPS-?/README.md
Outdated
| --- | ||
| CPS: ??? | ||
| Title: Cardano Governance Security | ||
| Category: ? |
There was a problem hiding this comment.
As this is directly related to the Ledger's governance implementation, I think Ledger is an appropriate category.
There was a problem hiding this comment.
While I love this CIP, and while it is hugely important and discusses things that the ledger care about, I don't think that it fits into how I was envisioning the Ledger Category in my draft RP.
The criterion for deciding if a change to the ledger merits a CIP was proposed to be as follows:
every implementation of the Cardano ledger needs to be standardized on the details.
There was a problem hiding this comment.
Fair enough, thanks for the insight @JaredCorduan.
I am unsure which category fits the best, perhaps Meta?
There was a problem hiding this comment.
yes @Ryun1 @JaredCorduan I would vote for Meta especially due to the wide range of areas each of these proposal components touch upon.
There was a problem hiding this comment.
Can I add @Liberty-Chris @rphair @Ryun1 @JaredCorduan as contributors or authors to this CPS? Not sure which one or what the industry standards are for CPS contributors, but I would like to credit people for their efforts.
There was a problem hiding this comment.
@rickymac68 I think that a Contributors section would be welcome but I may not have enough influence on the content to be listed as an Author (generally so for other editors).
There are likely to be a number of people who you want to credit as contributors by the time this CPS makes it through the process but we don't have an official section for it. The best I can think of is to add an H3 element (### Contributors) after the Abstract where you can list those you feel are key contributors.
|
|
||
| Recommendation: | ||
|
|
||
| ## Use Cases |
There was a problem hiding this comment.
Here you can add examples of user's goals, so for Ada holders it may be "to be able to engage in a safe and secure governance system where...."
|
Thank you for making this CIP @rickymac68 and getting the discussion going, I am very excited to see it! |
Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
Changes from CPS reviewers accepted. Co-authored-by: Liberty.Chris. <82896265+Liberty-Chris@users.noreply.github.com> Co-authored-by: Ryan Williams <44342099+Ryun1@users.noreply.github.com>
Changed the category to Meta and tried to make the format easier to read.
Wrote the recommended solutions for section 2 for review.
Added recommendations for an emergency change requiring a governance action. Also, swapped sections 2 and 3 for a more logical order.
Added cardano-foundation#26 Governance capture by a Layer 2 - for subject matter expert consideration and feedback.
|
|
||
| **Recommendation:Pre-planned Response** The person discovering the vulnerability should take the following steps: | ||
| * Document the vulnerability: The first step is to document the vulnerability as accurately as possible. This documentation should include a detailed description of the vulnerability, steps to reproduce it, and any other relevant information. | ||
| * Notify the relevant parties: The next step is to notify the appropriate parties, including the developers of the software, the blockchain community, and any relevant authorities. It's important to provide as much information as possible, so that the parties involved can understand the scope of the vulnerability and take the necessary steps to address it. |
There was a problem hiding this comment.
The "relevant parties" should (must?) be voted on by the community. The contact detail data could (must?) be stored on chain.
| * A security fix that must be implemented but the nature cannot be communicated publicly. | ||
| * The emergency change may, or may not, require a vote on a hard fork or parameter change. | ||
| * This section may be in respose to section #1 above, or for other emergencies bug fixes. | ||
| * The emergency change may have to be coordinated by IOG for the Haskell based Cardano nodes, or the primary software provider of any other Cardano node implementations. |
There was a problem hiding this comment.
I would avoid using any specifics in the CIP. IOG may or may not be the entity managing the Haskell nodes. Haskell may or may not be the language of nodes in the future.
|
|
||
| ### #2: Emergency change that needs to be done quickly. | ||
| * A nuclear option where the change requires “just do it” | ||
| * A security fix that must be implemented but the nature cannot be communicated publicly. |
There was a problem hiding this comment.
This won't be possible. The nodes are (currently) all open source and code is viewable by the public. Once the fix is known the bug is known.
| #### 2.A: For an Emergency change only requiring the SPOs, yet affects governance or voting: | ||
| 1. IOG provide the Stake Pool Operators with clear and concise instructions for implementing the software change. Emphasize that while the change is not mandatory, but must be implemented without delay. Explain: What is the impact? Communicate the urgency of the change to the SPOs, without providing specific details about the threat or catastrophic failure. The operators should be aware of the importance of the change, but not necessarily the reasons behind it. | ||
|
|
||
| 2. SMEs provide technical support to the SPOs as needed as they implement the change, if there are any hardware requirements, configuration file requirements, etc... Most SPOs are proficient but be careful to provide necessary details during emergency changes. Optimally software is tested on test nets first but a need may arise where use of the test net is not an option. |
There was a problem hiding this comment.
We should make risk categorizations which determine when/if a patch can go to mainnet with no or minimal validation in a testnet (actively being exploited, maybe direct to mainnet, else testnet[for how long?])
| * The emergency change may, or may not, require a vote on a hard fork or parameter change. | ||
| * This section may be in respose to section #1 above, or for other emergencies bug fixes. | ||
| * The emergency change may have to be coordinated by IOG for the Haskell based Cardano nodes, or the primary software provider of any other Cardano node implementations. | ||
|
|
There was a problem hiding this comment.
We may want to add some steps/notes about Cardano infrastructure providers? Something like Blockdaemon and/or Fireblocks, and also wallet infrastructure (Daedalus, Ledger, Lace, Nami, etc...).
|
|
||
| Notify the current Constituional Commitee of the person in charge of the Emergeny Group responsible for the disaster recovery so that they know any governance actions submitted by the group are valid, or that some level of trust is established. To minimize the risk of physical and cyber threats, The Emergency Group needs to protect their private keys and identities, and ensure that the Cardano network can be recovered in the event of a disaster. Notify Delegator Representatives as needed in the event that they and their keys are required to recover the Cardano network: | ||
|
|
||
| 1. (CF?) Identify and select a group of trusted individuals who will be responsible for disaster recovery. These individuals should be chosen based on their experience, skills, and trustworthiness. |
There was a problem hiding this comment.
Probably need to ensure they are generally geographically dispersed. May also want to ensure they do not travel together or any will be in the same place for a prolonged period of time.
| -overlapping actions and duplicate actions | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
Not sure there is a risk here. We would need all governing bodies to agree that the submitted proposal is 1) valid and 2) everyone votes to pass it.
| ### #19: Sybil behavior - one person acting as multiple DReps. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
If the voting power is based on total ADA behind the DRep then what point would there be to create multiple registrations? To bloat the the chain? You could argue the transaction cost to register as a DRep would make this unattractive in the same way spamming the network with tiny transactions prevents DDoS
| ### #22: High chain load impacting governance. | ||
|
|
||
| Recommendation: | ||
|
|
There was a problem hiding this comment.
iirc a layer2 can share the same security guarantees as a layer1 but a sidechain is just a bridged, separate network -- offloading to layer2 definitely sounds like a good idea
|
|
||
| ### #21: Superstar attack - one “superstar” person that everybody delegates to becomes a dictator with little skin in the game. | ||
| (Example: Elon Musk as a DRep) | ||
|
|
There was a problem hiding this comment.
Must be solved in the constitution (separation of powers again)
| ### #25: Ensuring the legitimacy of side chains involved in governance. | ||
|
|
||
| **Recommendation:** | ||
|
|
Ryun1
added
Category: Meta
KtorZ
added
Category: Ledger
|
@rickymac68 please rename the containing folder from |
Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com>
Co-authored-by: Matthias Benkort <5680256+KtorZ@users.noreply.github.com>
Ryun1
added
the
Waiting for Author
This PR for the Governance Security CPS which was previously in CIP formant. Reformatted to CPS template style and included the previously accepted changes from the CIP.
Rendered in branch