github.com/cosmos/cosmos-sdk@v0.50.10/docs/architecture/adr-008-dCERT-group.md (about) 1 # ADR 008: Decentralized Computer Emergency Response Team (dCERT) Group 2 3 ## Changelog 4 5 * 2019 Jul 31: Initial Draft 6 7 ## Context 8 9 In order to reduce the number of parties involved with handling sensitive 10 information in an emergency scenario, we propose the creation of a 11 specialization group named The Decentralized Computer Emergency Response Team 12 (dCERT). Initially this group's role is intended to serve as coordinators 13 between various actors within a blockchain community such as validators, 14 bug-hunters, and developers. During a time of crisis, the dCERT group would 15 aggregate and relay input from a variety of stakeholders to the developers who 16 are actively devising a patch to the software, this way sensitive information 17 does not need to be publicly disclosed while some input from the community can 18 still be gained. 19 20 Additionally, a special privilege is proposed for the dCERT group: the capacity 21 to "circuit-break" (aka. temporarily disable) a particular message path. Note 22 that this privilege should be enabled/disabled globally with a governance 23 parameter such that this privilege could start disabled and later be enabled 24 through a parameter change proposal, once a dCERT group has been established. 25 26 In the future it is foreseeable that the community may wish to expand the roles 27 of dCERT with further responsibilities such as the capacity to "pre-approve" a 28 security update on behalf of the community prior to a full community 29 wide vote whereby the sensitive information would be revealed prior to a 30 vulnerability being patched on the live network. 31 32 ## Decision 33 34 The dCERT group is proposed to include an implementation of a `SpecializationGroup` 35 as defined in [ADR 007](./adr-007-specialization-groups.md). This will include the 36 implementation of: 37 38 * continuous voting 39 * slashing due to breach of soft contract 40 * revoking a member due to breach of soft contract 41 * emergency disband of the entire dCERT group (ex. for colluding maliciously) 42 * compensation stipend from the community pool or other means decided by 43 governance 44 45 This system necessitates the following new parameters: 46 47 * blockly stipend allowance per dCERT member 48 * maximum number of dCERT members 49 * required staked slashable tokens for each dCERT member 50 * quorum for suspending a particular member 51 * proposal wager for disbanding the dCERT group 52 * stabilization period for dCERT member transition 53 * circuit break dCERT privileges enabled 54 55 These parameters are expected to be implemented through the param keeper such 56 that governance may change them at any given point. 57 58 ### Continuous Voting Electionator 59 60 An `Electionator` object is to be implemented as continuous voting and with the 61 following specifications: 62 63 * All delegation addresses may submit votes at any point which updates their 64 preferred representation on the dCERT group. 65 * Preferred representation may be arbitrarily split between addresses (ex. 50% 66 to John, 25% to Sally, 25% to Carol) 67 * In order for a new member to be added to the dCERT group they must 68 send a transaction accepting their admission at which point the validity of 69 their admission is to be confirmed. 70 * A sequence number is assigned when a member is added to dCERT group. 71 If a member leaves the dCERT group and then enters back, a new sequence number 72 is assigned. 73 * Addresses which control the greatest amount of preferred-representation are 74 eligible to join the dCERT group (up the _maximum number of dCERT members_). 75 If the dCERT group is already full and new member is admitted, the existing 76 dCERT member with the lowest amount of votes is kicked from the dCERT group. 77 * In the split situation where the dCERT group is full but a vying candidate 78 has the same amount of vote as an existing dCERT member, the existing 79 member should maintain its position. 80 * In the split situation where somebody must be kicked out but the two 81 addresses with the smallest number of votes have the same number of votes, 82 the address with the smallest sequence number maintains its position. 83 * A stabilization period can be optionally included to reduce the 84 "flip-flopping" of the dCERT membership tail members. If a stabilization 85 period is provided which is greater than 0, when members are kicked due to 86 insufficient support, a queue entry is created which documents which member is 87 to replace which other member. While this entry is in the queue, no new entries 88 to kick that same dCERT member can be made. When the entry matures at the 89 duration of the stabilization period, the new member is instantiated, and old 90 member kicked. 91 92 ### Staking/Slashing 93 94 All members of the dCERT group must stake tokens _specifically_ to maintain 95 eligibility as a dCERT member. These tokens can be staked directly by the vying 96 dCERT member or out of the good will of a 3rd party (who shall gain no on-chain 97 benefits for doing so). This staking mechanism should use the existing global 98 unbonding time of tokens staked for network validator security. A dCERT member 99 can _only be_ a member if it has the required tokens staked under this 100 mechanism. If those tokens are unbonded then the dCERT member must be 101 automatically kicked from the group. 102 103 Slashing of a particular dCERT member due to soft-contract breach should be 104 performed by governance on a per member basis based on the magnitude of the 105 breach. The process flow is anticipated to be that a dCERT member is suspended 106 by the dCERT group prior to being slashed by governance. 107 108 Membership suspension by the dCERT group takes place through a voting procedure 109 by the dCERT group members. After this suspension has taken place, a governance 110 proposal to slash the dCERT member must be submitted, if the proposal is not 111 approved by the time the rescinding member has completed unbonding their 112 tokens, then the tokens are no longer staked and unable to be slashed. 113 114 Additionally in the case of an emergency situation of a colluding and malicious 115 dCERT group, the community needs the capability to disband the entire dCERT 116 group and likely fully slash them. This could be achieved though a special new 117 proposal type (implemented as a general governance proposal) which would halt 118 the functionality of the dCERT group until the proposal was concluded. This 119 special proposal type would likely need to also have a fairly large wager which 120 could be slashed if the proposal creator was malicious. The reason a large 121 wager should be required is because as soon as the proposal is made, the 122 capability of the dCERT group to halt message routes is put on temporarily 123 suspended, meaning that a malicious actor who created such a proposal could 124 then potentially exploit a bug during this period of time, with no dCERT group 125 capable of shutting down the exploitable message routes. 126 127 ### dCERT membership transactions 128 129 Active dCERT members 130 131 * change of the description of the dCERT group 132 * circuit break a message route 133 * vote to suspend a dCERT member. 134 135 Here circuit-breaking refers to the capability to disable a groups of messages, 136 This could for instance mean: "disable all staking-delegation messages", or 137 "disable all distribution messages". This could be accomplished by verifying 138 that the message route has not been "circuit-broken" at CheckTx time (in 139 `baseapp/baseapp.go`). 140 141 "unbreaking" a circuit is anticipated only to occur during a hard fork upgrade 142 meaning that no capability to unbreak a message route on a live chain is 143 required. 144 145 Note also, that if there was a problem with governance voting (for instance a 146 capability to vote many times) then governance would be broken and should be 147 halted with this mechanism, it would be then up to the validator set to 148 coordinate and hard-fork upgrade to a patched version of the software where 149 governance is re-enabled (and fixed). If the dCERT group abuses this privilege 150 they should all be severely slashed. 151 152 ## Status 153 154 > Proposed 155 156 ## Consequences 157 158 ### Positive 159 160 * Potential to reduces the number of parties to coordinate with during an emergency 161 * Reduction in possibility of disclosing sensitive information to malicious parties 162 163 ### Negative 164 165 * Centralization risks 166 167 ### Neutral 168 169 ## References 170 171 [Specialization Groups ADR](./adr-007-specialization-groups.md)