变更记录
- 2019年7月31日：初稿
背景
为了减少在紧急情况下处理敏感信息所涉及的参与方数量，我们提议创建一个名为去中心化计算机应急响应团队（dCERT）的专业化小组。该小组最初的职责是作为区块链社区内各类参与者之间的协调者，例如验证者、漏洞猎人和开发者。在危机时期，dCERT 小组将汇总并转达来自不同利益相关方的意见，交给正在积极制定软件补丁的开发者；这样一来，敏感信息无需公开披露，同时仍然可以获得社区的一部分反馈。 此外，还为 dCERT 小组提出了一项特殊权限：对特定消息路径执行“断路”（即临时禁用）的能力。请注意，这项权限应通过治理参数在全局范围内启用或禁用，这样该权限可以一开始处于禁用状态，待 dCERT 小组建立后，再通过参数变更提案启用。 未来可以预见，社区可能希望进一步扩展 dCERT 的职责，例如赋予其在全社区投票之前代表社区“预先批准”安全更新的能力；否则，在漏洞尚未于线上网络修复之前，敏感信息就可能在全网投票过程中被披露。决策
dCERT 小组拟包含一个SpecializationGroup 的实现，定义见ADR 007。这将包括以下实现：
- 持续投票
- 因违反软契约而执行惩罚性削减
- 因违反软契约而撤销成员资格
- 紧急解散整个 dCERT 小组（例如恶意串通时）
- 由社区资金池或治理决定的其他方式提供补偿津贴
- 每位 dCERT 成员的区块津贴额度
- dCERT 成员最大数量
- 每位 dCERT 成员所需质押的可削减代币数量
- 暂停某一特定成员资格所需的法定人数
- 解散 dCERT 小组的提案质押金额
- dCERT 成员切换的稳定期
- 是否启用 dCERT 的断路权限
持续投票 Electionator
将实现一个Electionator 对象，用于持续投票，并满足以下规范：
- 所有委托地址都可以在任意时间提交投票，以更新其在 dCERT 小组中的偏好代表。
- 偏好代表可以在多个地址之间任意拆分（例如 50% 给 John，25% 给 Sally，25% 给 Carol）。
- 为了让新成员加入 dCERT 小组，其必须发送一笔交易以接受其准入，随后将确认该准入的有效性。
- 当成员加入 dCERT 小组时，会分配一个序列号。 如果某成员离开 dCERT 小组后再次加入，则会分配新的序列号。
- 控制最多偏好代表份额的地址有资格加入 dCERT 小组（直至达到dCERT 成员最大数量）。
如果 dCERT 小组已满且有新成员获准加入，则现有 dCERT 成员中得票最少者将被踢出 dCERT 小组。
- 在 dCERT 小组已满但竞争候选人与现有 dCERT 成员票数相同的情况下，现有成员应保留其位置。
- 在必须踢出某人但得票最少的两个地址票数相同的情况下，序列号较小的地址保留其位置。
- 可以选择引入稳定期，以减少 dCERT 成员名单尾部成员的“来回变动”。如果提供的稳定期大于 0，当成员因支持不足而被踢出时，会创建一个队列条目，记录由哪个成员替换哪个成员。在该条目位于队列中期间，不能再创建新的条目来踢出同一个 dCERT 成员。当条目在稳定期持续时间结束后成熟时，将实例化新成员，并踢出旧成员。
质押 / 削减
dCERT 小组的所有成员都必须专门质押代币，以维持其作为 dCERT 成员的资格。这些代币既可以由竞争 dCERT 席位的成员直接质押，也可以出于第三方善意由其代为质押（该第三方不会因此获得任何链上收益）。该质押机制应使用现有的、用于网络验证者安全的全局解绑时间。只有在该机制下质押了所需代币，dCERT 成员才能保持成员资格。如果这些代币被解绑，则该 dCERT 成员必须被自动踢出小组。 因违反软契约而对特定 dCERT 成员执行惩罚性削减，应由治理根据违规严重程度按成员逐个实施。预计流程是：某个 dCERT 成员先由 dCERT 小组暂停资格，然后再由治理对其进行削减。 由 dCERT 小组执行成员暂停资格时，需要通过 dCERT 小组成员之间的投票程序完成。在暂停生效后，必须提交一个治理提案以削减该 dCERT 成员；如果该提案在被撤销成员完成其代币解绑之前未获批准，则这些代币将不再处于质押状态，因而无法被削减。 此外，在 dCERT 小组发生串通且存在恶意行为的紧急情况下，社区需要具备解散整个 dCERT 小组并很可能对其全部成员执行完全削减的能力。这可以通过一种特殊的新提案类型来实现（作为通用治理提案实现），该提案会在其得出结论前暂停 dCERT 小组的功能。此特殊提案类型很可能还需要设置一个相当高的质押金额，如果提案创建者存在恶意，该质押可以被削减。之所以需要较高质押，是因为一旦该提案被提出，dCERT 小组暂停消息路由的能力也会被临时中止，这意味着恶意行为者可能在这段期间利用漏洞，而此时没有 dCERT 小组能够关闭可被利用的消息路由。dCERT 成员资格交易
活跃的 dCERT 成员可以执行：- 更改 dCERT 小组的描述
- 对某个消息路由执行断路
- 投票暂停某位 dCERT 成员资格
CheckTx 阶段（位于 baseapp/baseapp.go）验证该消息路由是否尚未被“断路”来实现。
预计“解除断路”只会在硬分叉升级期间发生，这意味着无需提供在运行中的链上解除某个消息路由断路状态的能力。
还需要注意，如果治理投票本身存在问题（例如可以重复投票的能力），那么治理将处于损坏状态，应通过该机制将其暂停。随后将由验证者集合进行协调，并通过硬分叉升级到已修补的软件版本，以重新启用（并修复）治理。如果 dCERT 小组滥用这项权限，则其所有成员都应受到严厉削减。
状态
提议中
影响
正面
- 在紧急情况下，有可能减少需要协调的参与方数量
- 降低向恶意参与方披露敏感信息的可能性
负面
- 中心化风险
中性
参考资料
专业化小组 ADRChangelog
- 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 aSpecializationGroup
as defined in ADR 007. 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
- 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
Continuous Voting Electionator
AnElectionator 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.
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