github.com/cosmos/cosmos-sdk@v0.50.10/docs/architecture/adr-007-specialization-groups.md (about) 1 # ADR 007: Specialization Groups 2 3 ## Changelog 4 5 * 2019 Jul 31: Initial Draft 6 7 ## Context 8 9 This idea was first conceived of in order to fulfill the use case of the 10 creation of a decentralized Computer Emergency Response Team (dCERT), whose 11 members would be elected by a governing community and would fulfill the role of 12 coordinating the community under emergency situations. This thinking 13 can be further abstracted into the conception of "blockchain specialization 14 groups". 15 16 The creation of these groups are the beginning of specialization capabilities 17 within a wider blockchain community which could be used to enable a certain 18 level of delegated responsibilities. Examples of specialization which could be 19 beneficial to a blockchain community include: code auditing, emergency response, 20 code development etc. This type of community organization paves the way for 21 individual stakeholders to delegate votes by issue type, if in the future 22 governance proposals include a field for issue type. 23 24 ## Decision 25 26 A specialization group can be broadly broken down into the following functions 27 (herein containing examples): 28 29 * Membership Admittance 30 * Membership Acceptance 31 * Membership Revocation 32 * (probably) Without Penalty 33 * member steps down (self-Revocation) 34 * replaced by new member from governance 35 * (probably) With Penalty 36 * due to breach of soft-agreement (determined through governance) 37 * due to breach of hard-agreement (determined by code) 38 * Execution of Duties 39 * Special transactions which only execute for members of a specialization 40 group (for example, dCERT members voting to turn off transaction routes in 41 an emergency scenario) 42 * Compensation 43 * Group compensation (further distribution decided by the specialization group) 44 * Individual compensation for all constituents of a group from the 45 greater community 46 47 Membership admittance to a specialization group could take place over a wide 48 variety of mechanisms. The most obvious example is through a general vote among 49 the entire community, however in certain systems a community may want to allow 50 the members already in a specialization group to internally elect new members, 51 or maybe the community may assign a permission to a particular specialization 52 group to appoint members to other 3rd party groups. The sky is really the limit 53 as to how membership admittance can be structured. We attempt to capture 54 some of these possiblities in a common interface dubbed the `Electionator`. For 55 its initial implementation as a part of this ADR we recommend that the general 56 election abstraction (`Electionator`) is provided as well as a basic 57 implementation of that abstraction which allows for a continuous election of 58 members of a specialization group. 59 60 ``` golang 61 // The Electionator abstraction covers the concept space for 62 // a wide variety of election kinds. 63 type Electionator interface { 64 65 // is the election object accepting votes. 66 Active() bool 67 68 // functionality to execute for when a vote is cast in this election, here 69 // the vote field is anticipated to be marshalled into a vote type used 70 // by an election. 71 // 72 // NOTE There are no explicit ids here. Just votes which pertain specifically 73 // to one electionator. Anyone can create and send a vote to the electionator item 74 // which will presumably attempt to marshal those bytes into a particular struct 75 // and apply the vote information in some arbitrary way. There can be multiple 76 // Electionators within the Cosmos-Hub for multiple specialization groups, votes 77 // would need to be routed to the Electionator upstream of here. 78 Vote(addr sdk.AccAddress, vote []byte) 79 80 // here lies all functionality to authenticate and execute changes for 81 // when a member accepts being elected 82 AcceptElection(sdk.AccAddress) 83 84 // Register a revoker object 85 RegisterRevoker(Revoker) 86 87 // No more revokers may be registered after this function is called 88 SealRevokers() 89 90 // register hooks to call when an election actions occur 91 RegisterHooks(ElectionatorHooks) 92 93 // query for the current winner(s) of this election based on arbitrary 94 // election ruleset 95 QueryElected() []sdk.AccAddress 96 97 // query metadata for an address in the election this 98 // could include for example position that an address 99 // is being elected for within a group 100 // 101 // this metadata may be directly related to 102 // voting information and/or privileges enabled 103 // to members within a group. 104 QueryMetadata(sdk.AccAddress) []byte 105 } 106 107 // ElectionatorHooks, once registered with an Electionator, 108 // trigger execution of relevant interface functions when 109 // Electionator events occur. 110 type ElectionatorHooks interface { 111 AfterVoteCast(addr sdk.AccAddress, vote []byte) 112 AfterMemberAccepted(addr sdk.AccAddress) 113 AfterMemberRevoked(addr sdk.AccAddress, cause []byte) 114 } 115 116 // Revoker defines the function required for a membership revocation rule-set 117 // used by a specialization group. This could be used to create self revoking, 118 // and evidence based revoking, etc. Revokers types may be created and 119 // reused for different election types. 120 // 121 // When revoking the "cause" bytes may be arbitrarily marshalled into evidence, 122 // memos, etc. 123 type Revoker interface { 124 RevokeName() string // identifier for this revoker type 125 RevokeMember(addr sdk.AccAddress, cause []byte) error 126 } 127 ``` 128 129 Certain level of commonality likely exists between the existing code within 130 `x/governance` and required functionality of elections. This common 131 functionality should be abstracted during implementation. Similarly for each 132 vote implementation client CLI/REST functionality should be abstracted 133 to be reused for multiple elections. 134 135 The specialization group abstraction firstly extends the `Electionator` 136 but also further defines traits of the group. 137 138 ``` golang 139 type SpecializationGroup interface { 140 Electionator 141 GetName() string 142 GetDescription() string 143 144 // general soft contract the group is expected 145 // to fulfill with the greater community 146 GetContract() string 147 148 // messages which can be executed by the members of the group 149 Handler(ctx sdk.Context, msg sdk.Msg) sdk.Result 150 151 // logic to be executed at endblock, this may for instance 152 // include payment of a stipend to the group members 153 // for participation in the security group. 154 EndBlocker(ctx sdk.Context) 155 } 156 ``` 157 158 ## Status 159 160 > Proposed 161 162 ## Consequences 163 164 ### Positive 165 166 * increases specialization capabilities of a blockchain 167 * improve abstractions in `x/gov/` such that they can be used with specialization groups 168 169 ### Negative 170 171 * could be used to increase centralization within a community 172 173 ### Neutral 174 175 ## References 176 177 * [dCERT ADR](./adr-008-dCERT-group.md)