github.com/fibonacci-chain/fbc@v0.0.0-20231124064014-c7636198c1e9/libs/cosmos-sdk/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   - continuous voting
    38   - slashing due to breach of soft contract
    39   - revoking a member due to breach of soft contract
    40   - emergency disband of the entire dCERT group (ex. for colluding maliciously) 
    41   - compensation stipend from the community pool or other means decided by
    42     governance
    43  
    44  This system necessitates the following new parameters: 
    45   - blockly stipend allowance per dCERT member 
    46   - maximum number of dCERT members 
    47   - required staked slashable tokens for each dCERT member 
    48   - quorum for suspending a particular member 
    49   - proposal wager for disbanding the dCERT group 
    50   - stabilization period for dCERT member transition
    51   - circuit break dCERT privileges enabled 
    52  
    53  These parameters are expected to be implemented through the param keeper such 
    54  that governance may change them at any given point. 
    55  
    56  ### Continuous Voting Electionator
    57  
    58  An `Electionator` object is to be implemented as continuous voting and with the
    59  following specifications:
    60   - All delegation addresses may submit votes at any point which updates their 
    61     preferred representation on the dCERT group. 
    62   - Preferred representation may be arbitrarily split between addresses (ex. 50%
    63     to John, 25% to Sally, 25% to Carol) 
    64   - In order for a new member to be added to the dCERT group they must 
    65     send a transaction accepting their admission at which point the validity of
    66     their admission is to be confirmed. 
    67     - A sequence number is assigned when a member is added to dCERT group. 
    68       If a member leaves the dCERT group and then enters back, a new sequence number
    69       is assigned.  
    70   - Addresses which control the greatest amount of preferred-representation are
    71     eligible to join the dCERT group (up the _maximum number of dCERT members_). 
    72     If the dCERT group is already full and new member is admitted, the existing
    73     dCERT member with the lowest amount of votes is kicked from the dCERT group.
    74     - In the split situation where the dCERT group is full but a vying candidate 
    75       has the same amount of vote as an existing dCERT member, the existing 
    76       member should maintain its position. 
    77     - In the split situation where somebody must be kicked out but the two
    78       addresses with the smallest number of votes have the same number of votes,
    79       the address with the smallest sequence number maintains its position.  
    80   - A stabilization period can be optionally included to reduce the
    81     "flip-flopping" of the dCERT membership tail members. If a stabilization
    82     period is provided which is greater than 0, when members are kicked due to
    83     insufficient support, a queue entry is created which documents which member is
    84     to replace which other member. While this entry is in the queue, no new entries
    85     to kick that same dCERT member can be made. When the entry matures at the
    86     duration of the  stabilization period, the new member is instantiated, and old
    87     member kicked.
    88  
    89  ### Staking/Slashing
    90  
    91  All members of the dCERT group must stake tokens _specifically_ to maintain
    92  eligibility as a dCERT member. These tokens can be staked directly by the vying
    93  dCERT member or out of the good will of a 3rd party (who shall gain no on-chain
    94  benefits for doing so). This staking mechanism should use the existing global
    95  unbonding time of tokens staked for network validator security. A dCERT member
    96  can _only be_ a member if it has the required tokens staked under this
    97  mechanism. If those tokens are unbonded then the dCERT member must be
    98  automatically kicked from the group.  
    99  
   100  Slashing of a particular dCERT member due to soft-contract breach should be
   101  performed by governance on a per member basis based on the magnitude of the
   102  breach.  The process flow is anticipated to be that a dCERT member is suspended
   103  by the dCERT group prior to being slashed by governance.  
   104  
   105  Membership suspension by the dCERT group takes place through a voting procedure
   106  by the dCERT group members. After this suspension has taken place, a governance
   107  proposal to slash the dCERT member must be submitted, if the proposal is not
   108  approved by the time the rescinding member has completed unbonding their
   109  tokens, then the tokens are no longer staked and unable to be slashed. 
   110  
   111  Additionally in the case of an emergency situation of a colluding and malicious
   112  dCERT group, the community needs the capability to disband the entire dCERT
   113  group and likely fully slash them. This could be achieved though a special new
   114  proposal type (implemented as a general governance proposal) which would halt
   115  the functionality of the dCERT group until the proposal was concluded. This
   116  special proposal type would likely need to also have a fairly large wager which
   117  could be slashed if the proposal creator was malicious. The reason a large
   118  wager should be required is because as soon as the proposal is made, the
   119  capability of the dCERT group to halt message routes is put on temporarily
   120  suspended, meaning that a malicious actor who created such a proposal could
   121  then potentially exploit a bug during this period of time, with no dCERT group
   122  capable of shutting down the exploitable message routes. 
   123  
   124  ### dCERT membership transactions
   125  
   126  Active dCERT members 
   127   - change of the description of the dCERT group
   128   - circuit break a message route
   129   - vote to suspend a dCERT member. 
   130  
   131  Here circuit-breaking refers to the capability to disable a groups of messages,
   132  This could for instance mean: "disable all staking-delegation messages", or
   133  "disable all distribution messages". This could be accomplished by verifying
   134  that the message route has not been "circuit-broken" at CheckTx time (in
   135  `baseapp/baseapp.go`). 
   136  
   137  "unbreaking" a circuit is anticipated only to occur during a hard fork upgrade
   138  meaning that no capability to unbreak a message route on a live chain is
   139  required. 
   140  
   141  Note also, that if there was a problem with governance voting (for instance a
   142  capability to vote many times) then governance would be broken and should be
   143  halted with this mechanism, it would be then up to the validator set to
   144  coordinate and hard-fork upgrade to a patched version of the software where
   145  governance is re-enabled (and fixed). If the dCERT group abuses this privilege
   146  they should all be severely slashed.
   147  
   148  ## Status
   149  
   150  > Proposed
   151  
   152  ## Consequences
   153  
   154  ### Positive
   155  
   156   - Potential to reduces the number of parties to coordinate with during an emergency 
   157   - Reduction in possibility of disclosing sensitive information to malicious parties
   158  
   159  ### Negative
   160  
   161   - Centralization risks
   162  
   163  ### Neutral
   164  
   165  ## References
   166   
   167    (Specialization Groups ADR)[./adr-007-specialization-groups.md]