certusone
/
cosmos-sdk
mirror of https://github.com/certusone/cosmos-sdk.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge PR #4827: ADR 007 / 008: Specialization Groups Abstraction / CERT Group 

* draft ADR 7

* working

* new CERT ADR seperated

* working

* ...

* complete ADR 007

* CERT Group ADR

* dCERT

* @fede membership admittance discussion

* @fedekunze comments

* @AdityaSripal CERT usefulness

* @AdityaSripal @jleni circuit breaker discussion

* proposal ids discussion

* Update docs/architecture/adr-008-dCERT-group.md

Co-Authored-By: Aditya <adityasripal@gmail.com>

* @AdityaSripal comments

* Apply suggestions from @alexanderbez

Co-Authored-By: Alexander Bezobchuk <alexanderbez@users.noreply.github.com>

* Update docs/architecture/adr-007-specialization-groups.md

* Update docs/architecture/adr-008-dCERT-group.md

* Update docs/architecture/adr-008-dCERT-group.md

* Update docs/architecture/adr-008-dCERT-group.md

* Update docs/architecture/adr-008-dCERT-group.md

* Update docs/architecture/adr-008-dCERT-group.md

Co-Authored-By: Marko <marbar3778@yahoo.com>

* @alexanderbez comments

* blockchain agnostic per @cwgoes comment

* Apply suggestions from code review

Co-Authored-By: Alexander Bezobchuk <alexanderbez@users.noreply.github.com>

* @alexanderbez second pass comments

* stablization period, and delegating dCERT stake discussion
This commit is contained in:
frog power 4000 2019-09-30 15:05:29 -04:00 committed by GitHub
parent 6db739823b
commit 87740a53c3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 346 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

179
docs/architecture/adr-007-specialization-groups.md Normal file
View File

@ -0,0 +1,179 @@
# ADR 007: Specialization Groups
## Changelog
- 2019 Jul 31: Initial Draft
## Context
This idea was first conceived of in order to fulfill the use case of the
creation of a decentralized Computer Emergency Response Team (dCERT), whose
members would be elected by a governing community and would fulfill the role of
coordinating the community under emergency situations. This thinking
can be further abstracted into the conception of "blockchain specialization
groups".
The creation of these groups are the beginning of specialization capabilities
within a wider blockchain community which could be used to enable a certain
level of delegated responsibilities. Examples of specialization which could be
beneficial to a blockchain community include: code auditing, emergency response,
code development etc. This type of community organization paves the way for
individual stakeholders to delegate votes by issue type, if in the future
governance proposals include a field for issue type.
## Decision
A specialization group can be broadly broken down into the following functions
(herein containing examples):
- Membership Admittance
- Membership Acceptance
- Membership Revocation
- (probably) Without Penalty
- member steps down (self-Revocation)
- replaced by new member from governance
- (probably) With Penalty
- due to breach of soft-agreement (determined through governance)
- due to breach of hard-agreement (determined by code)
- Execution of Duties
- Special transactions which only execute for members of a specialization
group (for example, dCERT members voting to turn off transaction routes in
an emergency scenario)
- Compensation
- Group compensation (further distribution decided by the specialization group)
- Individual compensation for all constituents of a group from the
greater community
Membership admittance to a specialization group could take place over a wide
variety of mechanisms. The most obvious example is through a general vote among
the entire community, however in certain systems a community may want to allow
the members already in a specialization group to internally elect new members,
or maybe the community may assign a permission to a particular specialization
group to appoint members to other 3rd party groups. The sky is really the limit
as to how membership admittance can be structured. We attempt to capture
some of these possiblities in a common interface dubbed the `Electionator`. For
its initial implementation as a part of this ADR we recommend that the general
election abstraction (`Electionator`) is provided as well as a basic
implementation of that abstraction which allows for a continuous election of
members of a specialization group.
``` golang
// The Electionator abstraction covers the concept space for
// a wide variety of election kinds.
type Electionator interface {
// is the election object accepting votes.
Active() bool
// functionality to execute for when a vote is cast in this election, here
// the vote field is anticipated to be marshalled into a vote type used
// by an election.
//
// NOTE There are no explicit ids here. Just votes which pertain specifically
// to one electionator. Anyone can create and send a vote to the electionator item
// which will presumably attempt to marshal those bytes into a particular struct
// and apply the vote information in some arbitrary way. There can be multiple
// Electionators within the Cosmos-Hub for multiple specialization groups, votes
// would need to be routed to the Electionator upstream of here.
Vote(addr sdk.AccAddress, vote []byte)
// here lies all functionality to authenticate and execute changes for
// when a member accepts being elected
AcceptElection(sdk.AccAddress)
// Register a revoker object
RegisterRevoker(Revoker)
// No more revokers may be registered after this function is called
SealRevokers()
// register hooks to call when an election actions occur
RegisterHooks(ElectionatorHooks)
// query for the current winner(s) of this election based on arbitrary
// election ruleset
QueryElected() []sdk.AccAddress
// query metadata for an address in the election this
// could include for example position that an address
// is being elected for within a group
//
// this metadata may be directly related to
// voting information and/or privileges enabled
// to members within a group.
QueryMetadata(sdk.AccAddress) []byte
}
// ElectionatorHooks, once registered with an Electionator,
// trigger execution of relevant interface functions when
// Electionator events occur.
type ElectionatorHooks interface {
AfterVoteCast(addr sdk.AccAddress, vote []byte)
AfterMemberAccepted(addr sdk.AccAddress)
AfterMemberRevoked(addr sdk.AccAddress, cause []byte)
}
// Revoker defines the function required for a membership revocation rule-set
// used by a specialization group. This could be used to create self revoking,
// and evidence based revoking, etc. Revokers types may be created and
// reused for different election types.
//
// When revoking the "cause" bytes may be arbitrarily marshalled into evidence,
// memos, etc.
type Revoker interface {
RevokeName() string // identifier for this revoker type
RevokeMember(addr sdk.AccAddress, cause []byte) error
}
```
Certain level of commonality likely exists between the existing code within
`x/governance` and required functionality of elections. This common
functionality should be abstracted during implementation. Similarly for each
vote implementation client CLI/REST functionality should be abstracted
to be reused for multiple elections.
The specialization group abstraction firstly extends the `Electionator`
but also further defines traits of the group.
``` golang
type SpecializationGroup interface {
Electionator
GetName() string
GetDescription() string
// general soft contract the group is expected
// to fulfill with the greater community
GetContract() string
// messages which can be executed by the members of the group
Handler(ctx sdk.Context, msg sdk.Msg) sdk.Result
// logic to be executed at endblock, this may for instance
// include payment of a stipend to the group members
// for participation in the security group.
EndBlocker(ctx sdk.Context)
}
```
## Status
> Proposed
## Consequences
### Positive
- increases specialization capabilities of a blockchain
- improve abstractions in `x/gov/` such that they can be used with specialization groups
### Negative
- could be used to increase centralization within a community
### Neutral
## References
- (dCERT ADR)[./adr-008-dCERT-group.md]

167
docs/architecture/adr-008-dCERT-group.md Normal file
View File

@ -0,0 +1,167 @@
# ADR 008: Decentralized Computer Emergency Response Team (dCERT) Group
## Changelog
- 2019 Jul 31: Initial Draft
## Context
In order to reduce the number of parties involved with handling sensitive
information in an emergency scenario, we propose the creation of a
specialization group named The Decentralized Computer Emergency Response Team
(dCERT). Initially this group's role is intended to serve as coordinators
between various actors within a blockchain community such as validators,
bug-hunters, and developers. During a time of crisis, the dCERT group would
aggregate and relay input from a variety of stakeholders to the developers who
are actively devising a patch to the software, this way sensitive information
does not need to be publicly disclosed while some input from the community can
still be gained.
Additionally, a special privilege is proposed for the dCERT group: the capacity
to "circuit-break" (aka. temporarily disable) a particular message path. Note
that this privilege should be enabled/disabled globally with a governance
parameter such that this privilege could start disabled and later be enabled
through a parameter change proposal, once a dCERT group has been established.
In the future it is foreseeable that the community may wish to expand the roles
of dCERT with further responsibilities such as the capacity to "pre-approve" a
security update on behalf of the community prior to a full community
wide vote whereby the sensitive information would be revealed prior to a
vulnerability being patched on the live network.
## Decision
The dCERT group is proposed to include an implementation of a `SpecializationGroup`
as defined in [ADR 007](./adr-007-specialization-groups.md). This will include the
implementation of:
- continuous voting
- slashing due to breach of soft contract
- revoking a member due to breach of soft contract
- emergency disband of the entire dCERT group (ex. for colluding maliciously)
- compensation stipend from the community pool or other means decided by
governance
This system necessitates the following new parameters:
- blockly stipend allowance per dCERT member
- maximum number of dCERT members
- required staked slashable tokens for each dCERT member
- quorum for suspending a particular member
- proposal wager for disbanding the dCERT group
- stabilization period for dCERT member transition
- circuit break dCERT privileges enabled
These parameters are expected to be implemented through the param keeper such
that governance may change them at any given point.
### Continuous Voting Electionator
An `Electionator` object is to be implemented as continuous voting and with the
following specifications:
- All delegation addresses may submit votes at any point which updates their
preferred representation on the dCERT group.
- Preferred representation may be arbitrarily split between addresses (ex. 50%
to John, 25% to Sally, 25% to Carol)
- In order for a new member to be added to the dCERT group they must
send a transaction accepting their admission at which point the validity of
their admission is to be confirmed.
- A sequence number is assigned when a member is added to dCERT group.
If a member leaves the dCERT group and then enters back, a new sequence number
is assigned.
- Addresses which control the greatest amount of preferred-representation are
eligible to join the dCERT group (up the _maximum number of dCERT members_).
If the dCERT group is already full and new member is admitted, the existing
dCERT member with the lowest amount of votes is kicked from the dCERT group.
- In the split situation where the dCERT group is full but a vying candidate
has the same amount of vote as an existing dCERT member, the existing
member should maintain its position.
- In the split situation where somebody must be kicked out but the two
addresses with the smallest number of votes have the same number of votes,
the address with the smallest sequence number maintains its position.
- A stabilization period can be optionally included to reduce the
"flip-flopping" of the dCERT membership tail members. If a stabilization
period is provided which is greater than 0, when members are kicked due to
insufficient support, a queue entry is created which documents which member is
to replace which other member. While this entry is in the queue, no new entries
to kick that same dCERT member can be made. When the entry matures at the
duration of the stabilization period, the new member is instantiated, and old
member kicked.
### Staking/Slashing
All members of the dCERT group must stake tokens _specifically_ to maintain
eligibility as a dCERT member. These tokens can be staked directly by the vying
dCERT member or out of the good will of a 3rd party (who shall gain no on-chain
benefits for doing so). This staking mechanism should use the existing global
unbonding time of tokens staked for network validator security. A dCERT member
can _only be_ a member if it has the required tokens staked under this
mechanism. If those tokens are unbonded then the dCERT member must be
automatically kicked from the group.
Slashing of a particular dCERT member due to soft-contract breach should be
performed by governance on a per member basis based on the magnitude of the
breach. The process flow is anticipated to be that a dCERT member is suspended
by the dCERT group prior to being slashed by governance.
Membership suspension by the dCERT group takes place through a voting procedure
by the dCERT group members. After this suspension has taken place, a governance
proposal to slash the dCERT member must be submitted, if the proposal is not
approved by the time the rescinding member has completed unbonding their
tokens, then the tokens are no longer staked and unable to be slashed.
Additionally in the case of an emergency situation of a colluding and malicious
dCERT group, the community needs the capability to disband the entire dCERT
group and likely fully slash them. This could be achieved though a special new
proposal type (implemented as a general governance proposal) which would halt
the functionality of the dCERT group until the proposal was concluded. This
special proposal type would likely need to also have a fairly large wager which
could be slashed if the proposal creator was malicious. The reason a large
wager should be required is because as soon as the proposal is made, the
capability of the dCERT group to halt message routes is put on temporarily
suspended, meaning that a malicious actor who created such a proposal could
then potentially exploit a bug during this period of time, with no dCERT group
capable of shutting down the exploitable message routes.
### dCERT membership transactions
Active dCERT members
- change of the description of the dCERT group
- circuit break a message route
- vote to suspend a dCERT member.
Here circuit-breaking refers to the capability to disable a groups of messages,
This could for instance mean: "disable all staking-delegation messages", or
"disable all distribution messages". This could be accomplished by verifying
that the message route has not been "circuit-broken" at CheckTx time (in
`baseapp/baseapp.go`).
"unbreaking" a circuit is anticipated only to occur during a hard fork upgrade
meaning that no capability to unbreak a message route on a live chain is
required.
Note also, that if there was a problem with governance voting (for instance a
capability to vote many times) then governance would be broken and should be
halted with this mechanism, it would be then up to the validator set to
coordinate and hard-fork upgrade to a patched version of the software where
governance is re-enabled (and fixed). If the dCERT group abuses this privilege
they should all be severely slashed.
## Status
> Proposed
## Consequences
### Positive
- Potential to reduces the number of parties to coordinate with during an emergency
- Reduction in possibility of disclosing sensitive information to malicious parties
### Negative
- Centralization risks
### Neutral
## References
(Specialization Groups ADR)[./adr-007-specialization-groups.md]