[Korean & Chinese Version Below]

Criteria for Proposals that Require Referendum

EOS utilizes a unique consensus protocol known as Delegated Proof of Stake (DPoS). On-chain governance and voting make DPoS particularly agile when compared to other consensus mechanisms. For example, Block Producers (BPs) rankings are bound to voting changes every 126 seconds. Additionally, on-chain voting determines hard coded changes that affect system contracts, use of network funds, and other crucial aspects of the EOS blockchain.

Two voting mechanisms allow changes to made — referendum and 15/21 BP supermajority.

  1. Referendum is a process by which the EOS community votes on proposals. In order for a proposal that goes through referendum to be implemented, the EOS community needs to vote 15% of tokens and no fewer than 10% more ‘Yes’ votes than ‘No’ votes, sustained for 30 continuous days within a 120 day period.
  2. BP supermajority requires 15 out of the top 21 Block Producers to approve a proposal in order to pass. As of October 2018, all changes made to the EOS blockchain have been done through the process of BP supermajority.

Note: The referendum contract has not been completely developed. Therefore, not a single proposal has been proposed or passed on the basis of referendum.

Surprisingly, little discussion has been afforded to defining an in-depth protocol for when proposals require referendum, versus a 15/21 super majority. With so much at stake, we need a formal protocol that outlines which voting mechanism a given proposal is subjected to before potentially being promulgated.

The following criteria was developed as an extension of the underlying principles of Article VIII in the EOS Platform User Agreement. Furthermore, EOS42 intends to advocate the following criteria until a formal article is ratified.

Overarching Goal: Balance the necessity for communal sovereignty, efficiency, and protection.

Communal Sovereignty: The community should always maintain ultimate authority over changes that directly influence governance or network economics.

Efficiency: Changes need to be made to the EOS core code on a regular basis for general enhancements, bug patches or potential emergencies. Subjecting these types of changes to referendum would bring EOS development to a halt.

Protection: Checks and balances are needed to decentralize power. The community acts as a buffer against the potential for BPs to enact policy that is plutocratic in nature.

Criteria:

  1. All new governing documents require referendum.
  2. Changes to an existing governing document requires referendum, unless the change is performed to fix a bug in code and has no effect on the underlying economics or intention of said document i.e. the fix is politically and/or objectively neutral.
  3. From this point forward, any proposal for system changes will need to indicate whether said proposal is a governing document.
  4. Defining features for governing documents:
  • The constitution is a governing document.
  • All proposals, contracts, or documents that affect any feature of the EOS economy, including direct use of any network fund, or direct influence upon any network fund i.e. , {claimrewards} (inflation), {buyram} (RAM fees), WPS (eosio.saving), REX proposal (name fees, RAM fees).
  • Any proposal, contract, or document that affects jurisdiction over BPs i.e. {voteproducer}, {regproducer}, {constitution}.
  • Any proposal, contract, or document that affects jurisdiction over arbitration and/or dispute resolution, i.e. {regforum} or {regarbiter}
  • Any proposal that affects voting.

5. Using this criteria, the following are currently governing documents: Constitution, {regproducer}, {voteproducer}, {buyram}, {buyrambytes}, {claimrewards}.

6. Examples of proposals that would be considered governing documents: {regforum}, {regarbitrator}, any WPS proposal, REX proposal.

7. All changes made outside of governing docs are eligible for a 15/21 vote.

EOS42 — Pioneering a Decentralized Future

WEBSITE

TWITTER

TELEGRAM

MEDIUM

STEEM

EOS42 PROJECTS:

CHINTAI (EOS Token Leasing)

EOS911 (Lost Key and Theft Support)

MEOW (My EOS Wallet)

[한국어/ Korean Translation]

국민 투표가 필요한 Proposal (제안) 이란?

EOS는 Delegated Proof of Stake (DPoS) 라고 하는 독창적인 합의 프로토콜을 사용합니다. 온-체인 (on-chain) 거버넌스와 투표는 DPoS를 다른 합의 프로토콜에 비해 빠르게 만듭니다. 예를 들어 Block Producers (BPs) 순위는 126 초마다 투표 변경사항에 따라 반영됩니다. 또한 온-체인 투표는 시스템 컨트랙트, 네트워크 펀드의 사용 등의 EOS 블록체인의 중요한 측면에 영향을 주는 코드 변경을 결정합니다.

이를 위한 두 개의 투표 메커니즘이 있습니다. 국민투표와 BP 15/21의 초대다수 채택입니다.

1. 국민 투표 (Referendum)는 EOS 커뮤니티가 제안서에 투표하는 과정입니다. 국민 투표를 실시하는 제안이 시행되기 위해서는 EOS 커뮤니티는 전체 토큰의 15% 를 투표해야 하고 ‘No’ 투표보다 10 % 이상 ‘Yes’ 에 투표를 해야 하며 120 일 이내에 30 일 동안 지속되어야 합니다.

2. BP의 초대다수 채택을 위해선 상위 21 명의 Block Producers 중 15 명이 제안에 승인해야 합니다. 2018 년 10월 현재 EOS 블록 체인에 대한 모든 변경 사항은 BP 초대다수 과정을 통해 이루어졌습니다.

참고사항: 국민투표 컨트랙트는 아직 완전히 개발되지 않았습니다. 따라서 아직 국민투표로 제안이 통과된 건은 한 건도 없습니다.

놀랍게도 국민투표를 필요로 하는 제안 vs. BP 다수 결정을 필요로 하는 제안둘중 어떤 제안에 어떤 투표를 사용해야 하는지 대한 토론이 별로 이루어 지지 않았습니다. 앞으로 제안들이 공표되기 전에 어떤 투표 메커니즘이 적용되는지 설명하는 공식적인 절차가 분명 필요하게 될 것입니다.

다음 기준은 EOS 플랫폼 사용자 동의서 제 8조의 기본 원칙을 확장하기 위해 쓰여졌습니다. 또한 EOS42 는 공식문서가 비준되기 전까지 다음의 기준을 지지하려고 합니다.

포괄적인 목표 (Overarching Goal): 공동의 주권, 효율성, 및 보호의 필요성을 조화롭게 합니다.

공동의 주권 (Community Sovereignty): 커뮤니티는 항상 거버넌스나 네트워크 경제에 직접적인 영향을 미치는 변화에 대해 궁극적인 통치권을 가지고 있어야 합니다.

효율성 (Efficiency): 일반적인 개선사항, 버그패치 또는 잠재적 응급상황을 위해 EOS 핵심코드를 정기적으로 변경해야 합니다. 이 부분에 국민투표(Referendum) 를 반영하면 EOS 개발이나 운영이 중단될 것입니다.

보호 (Protection): 탈중앙화를 위해 결제와 균형이 필요합니다. 커뮤니티는 금권주의적 정책을 제정하려는 잠재적 BP들을 막을 수 있는 역할을 해야 합니다.

국민투표 사용 기준 (Criteria):

1. 모든 새로운 정책 문서 (governing documents) 는 국민투표가 필요합니다.

2. 기존 정책 문서의 변경은 국민투표가 필요합니다. 하지만 응급사항, 버그패치 또는 기본적으로 경제적, 정치적으로 영향을 끼치지 않는 개선사항 등은 제외합니다.

3. 이 시점부터, 시스템 변경에 대한 제안은 정책문서인지 여부를 표시해야합니다.

4. 정책 문서에 대한 정의 및 기능:

  • 헌법은 정책 문서 입니다.
  • 네트워크 펀드의 직접 사용 또는 네트워크 펀드에 대한 직접적인 영향 즉, {claimrewards} (인플레이션), {buyram} (RAM 수수료), WPS 등 모든 EOS 경제에 영향을주는 모든 제안서, 계약서 또는 문서 (eosio.saving), REX 제안 (이름 수수료, RAM 수수료).
  • BP, 즉 {voteproducer}, {regproducer}, {constitution}에 대한 관할권에 영향을 주는 제안서, 계약서 또는 문서.
  • {regforum} 또는 {regarbiter}와 같은 중재 및 / 또는 분쟁 해결에 대한 관할권에 영향을 주는 모든 제안서, 계약서 또는 문서
  • 투표에 영향을 미치는 모든 제안

5. 위 기준을 사용하면 기존의 정책문서는 다음과 같습니다. 헌법, {regproducer}, {voteproducer}, {buyram}, {buyrambytes}, {claimrewards}

6. 정책 문서로 간주될 제안(proposal)의 예: {regforum}, {regarbitrator}, 모든 WPS 제안서, REX 제안서

7. 정책 문서를 제외한 모든 변경 사항은 BP 들의 15/21 표결에 해당됩니다.

EOS42 — Pioneering a Decentralized Future

[Chinese]

EOS采用了一种独特的共识协议,称为委托权益证明算法(Delegated Proof of Stake, DPos).

链上治理和投票的存在,使得DPoS与其他共识机制相比极为灵活。例如,出块节点(Block Producers) 的排名会根据投票状况,每126s变动一次。另外,在关系到系统合约的硬编码改动、网络资金使用以及EOS区块链的其他关键方面,链上投票会起决定作用。

进行变更的两种投票机制 — 公投和15/21 的BP超级多数表决。

  1. 公民投票是EOS社区对提案进行投票的过程。为了使经过公投的提案得以实施,EOS社区需要有15%的代币参与投票,且“赞成”的票数超过“反对”的票数,要不少于10%,在120天的时间内持续30天。
  2. BP超级多数通过的方式,要求在前21个出块节点(Block Producers)中有15家批准一项提案,才能获得通过。截至2018年10月,所有对EOS区块链的修改都是通过BP 超级多数的流程完成的。

备注: 当前公投合约的开发还未完全完成。因此,现在还没有使用公投的方式,发起或者通过一项提案。
奇怪的是,很少有人讨论如何定义一个深化的协议,决定何时我们需要进行全民公投而不是采用15/21的超级多数的方式。有这么多利害攸关的问题,我们需要一个正式的协议来规定某一提案在可能得到颁布之前,应使用哪种投票机制。

作为对EOS平台用户协议第8条的基本原则的扩展,制定了如下的标准。此外,EOS42打算提倡以下标准,直到正式的条款批准。

总体目标:平衡对公共主权、效率和保护的需求。
公共主权:对直接影响治理或网络经济的变更,社区应始终保持最终的权威性。
效率: 需要定期对EOS核心代码进行修改,以进行常规的优化、bug修复或应对潜在的紧急情况。如果对这些类型的变化进行公民投票,则会使EOS的发展陷入停滞。
保护: 权力的去中心化,需要相互制衡。针对出块节点(BP)制定属于富人统治性质的政策的潜在可能,社区起到了缓冲作用。

标准:

  1. 所有的新的治理文件,都需要进行公投。
  2. 对现有治理文件的变更,需要公投,除非该变更是用于修改代码bug或者对所涉及文档的潜在经济和意图无影响,即所涉变更是政治中立和/或客观中立的。
  3. 由此延伸,任何关于系统变更的提议都需要表明该提议是否是治理文件。
  4. 对 治理文件特性的定义:
    * 公约属于治理文件.
    * 所有的影响到EOS经济体特征的提案,合约,或者文件,包括对任何网络资产的直接使用,或者对任何网络资产的直接影响,即,{claimrewards}(通胀),{buyram}(RAM 手续费), WPS(eosio.saving), REX提案(账户名拍卖费,RAM手续费)。
    * 任何影响BPg管辖权的提案、合约或文件,即 {voteproducer}, {regproducer}, {constitution}.
    * 任何影响仲裁和/或争议解决管辖权的提案、合约或文件, 即{regforum} 或 {regarbiter}
    * 任何影响到投票的提案。
  5. 基于这一标准,如下的内容目前属于治理文件: 公约,{regproducer}, {voteproducer}, {buyram}, {buyrambytes}, {claimrewards}.
  6. 将会被视为治理文件的一些例子: {regforum}, {regarbitrator}, 任何 WPS 提案,以及 REX提案。
  7. 其他不属于治理文件类别的变更,都适用于15/21投票的方式。

EOS42 — Pioneering a Decentralized Future