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)