​
变更记录

  • 2019 年 7 月 31 日：初稿

​
背景

这个想法最初是为了满足去中心化计算机应急响应团队（dCERT）的使用场景而提出的。该团队的成员将由治理社区选举产生，并在紧急情况下承担协调社区的职责。这一思路还可以进一步抽象为“区块链专业化小组”的概念。 这些小组的建立，标志着更广泛的区块链社区开始具备专业化能力，可用于实现一定程度的职责委托。对区块链社区有益的专业化示例包括：代码审计、紧急响应、代码开发等。如果未来治理提案中包含问题类型字段，这种社区组织形式也为单个利益相关者按议题类型委托投票铺平了道路。

​
决策

一个专业化小组大致可以拆分为以下职能（此处包含示例）：
  • 成员准入
  • 成员接受
  • 成员撤销
    • （可能）无惩罚
      • 成员主动退出（自我撤销）
      • 由治理选出的新成员替换
    • （可能）有惩罚
      • 因违反软性协议（通过治理判定）
      • 因违反硬性协议（由代码判定）
  • 职责执行
    • 仅对专业化小组成员执行的特殊交易（例如，在紧急场景下，dCERT 成员投票关闭交易路由）
  • 补偿
    • 小组补偿（进一步分配由专业化小组决定）
    • 更大社区向小组所有成员提供的个人补偿
专业化小组的成员准入可以通过多种机制实现。最明显的例子是由整个社区进行普遍投票；不过在某些系统中，社区可能希望允许专业化小组现有成员内部选举新成员，或者社区也可能授予某个专业化小组向其他第三方小组任命成员的权限。成员准入的结构方式几乎没有上限。我们尝试在一个名为 Electionator 的通用接口中覆盖其中一些可能性。作为本 ADR 的初始实现，我们建议提供通用选举抽象（Electionator），以及该抽象的一个基础实现，以支持专业化小组成员的持续性选举。 
// 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
}
现有 x/governance 中的代码与选举所需功能之间，很可能存在一定程度的共性。这些通用功能应在实现过程中抽象出来。同样，对于每种投票实现，其客户端 CLI/REST 功能也应进行抽象，以便在多个选举之间复用。 专业化小组抽象首先扩展了 Electionator，同时进一步定义了小组的特征。 
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)
}

​
状态

提议中

​
影响

​
正面

  • 提升区块链的专业化能力
  • 改进 x/gov/ 中的抽象，使其可用于专业化小组

​
负面

  • 可能被用来增加社区内部的中心化程度

​
中性

​
参考

​
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. 
// 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. 
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