从RAM增发1.5G事件 看EOS提案机制

1、工作提案

愿景：EOS持有者可以通过投票选择一些可以让社区受益的工作提案，比如说想做一个全民投票工具等任何对EOS生态有益的事情，通过的提案将根据得票率获得部分系统增发的提案基金。

执行：需要明确的社区来支持工作提案应该是什么样子，它应该用来解决什么问题，以及它最终能达到的效果。

拟定流程：

1、提出提案；

2、讨论和改进提案；

3、正式提交提案，申请资金；

4、批准并分配提案基金；

5、监督资金使用情况；

6、风险管控；

7、提案机制的修正和改进。

需求：需要明确规定并记录下执行上述程序所需的智能合约。

工作提案章程文档见：

https://drive.google.com/file/d/1xlRZe9xR3d90f9VcVHaDuZmLU-i5b_33/view

2、系统更新提案

2.1 EOS系统合约代码多签更新案例

1、7月23号阿根廷超级节点通过命令行在EOS主网上发起多签提案1dot1dotzero，提案中包含了B1提交的待更新代码。

2、各超级节点对此提案的代码进行review，陆续通过（代码是B1写的，也有经过单元测试，所以节点们并没有对其功能做特别的验证）。

3、7月26号下午两点半超级节点liberty通过了该提案，至此通过的超级节点数量达到15个，此提案可执行。

4、十分钟后超级节点liberty在主网上执行了该提案，EOS主网系统合约代码立即更新，其中就包括计算第一次扩容的RAM数量。但由于其中某个参数错误地初始化为0，导致计算出来第一次新增发的RAM量为1.5个G，使得RAM总量瞬间扩容到65.5G。

2.2 现有流程

1、B1或BP针对某个bug或者某个现象进行讨论，提出多种解决方案；

2、方案提出方进行更新代码的开发。主要包括bug修复或是添加新功能等；

3、开发完成后公布代码或直接在主网上发起更新提案；

4、各出块节点对新代码进行review；

5、签名或通过；

6、签名或通过数达到15时，执行该更新。

其中，3～6步是开发完成后更新系统合约的步骤，落实到具体执行层面，主要有两种方法：

a、直接更新

每个出块节点需要做的：

1、将现有系统合约的wast和abi文件保存至本地

2、生成更新系统合约的未签名transaciton：upgrade_system_contract_trx.json

牵头出块节点要做的：

3、修改upgrade_system_contract_trx.json为

upgrade_system_contract_official_trx.json，并修改过期时间

4、将upgrade_system_contract_official_trx.json交给其它出块节点

每个出块节点需要做的：

5、将自己的upgrade_system_contract_trx.json和upgrade_system_contract_official_trx.json进行比较，验证提交代码的一致性

6、验证通过，各出块节点对

upgrade_system_contract_official_trx.json进行签名，并将签名后的哈希值交给牵头出块节点

牵头出块节点要做的：

7、复制upgrade_system_contract_official_trx.json为upgrade_system_contract_official_trx_signed.json，并将15个出块节点的签名哈希值加入upgrade_system_contract_official_trx_signed.json

8、向区块链push签名后的transaciton：upgrade_system_contract_official_trx_signed.json，完成更新

b、多签更新

1、任意BP（任何人都可以）通过命令行在EOS主网上发起包含新代码的多签提案。

2、各出块节点对此提案的代码进行review，主要是验证提案内代码的一致性，即提案代码与开发方公布的新代码是否一致。若出块节点对此提案认同，且一致性验证通过，则可在主网上签名approve该提案。

3、approve数量达到15个，且提案未过期时，任意BP（任何人都可以）通过命令行在EOS主网上执行该提案，执行后新代码立即生效。

2.3 存在的问题

对于与社区成员利益直接或间接相关的提案，主要存在以下问题：

1、信息披露不够

• 解决方案提出时未披露相关信息

• 代码开发完成后未披露更新后的情况

• 提案通过后执行前未给社区成员一定的缓冲时间

2、如何体现共识

• 如何确保各个节点在投票时最大程度上代表了该节点社区成员的共识？

3、代码审计缺失

• 如何审计开发的新代码？确保没有大bug，没有后门，且与向社区成员披露的信息一致

2.4 解决草案

核心思想：优化现有流程，增加信息披露步骤，提高信息透明度，在最大程度征集社区成员意见的基础上行使投票权。优化后的流程如下：

1、B1或BP针对某个bug或者某个现象进行讨论，提出多种解决方案（该阶段一般是在每周四晚9点的全球BP会议上进行，有涉及到与社区成员利益直接或间接相关的提案时，需及时向社区成员通告，当然各位小伙伴也可直接观看会议现场直播）；

2、方案提出方进行更新代码的开发。主要包括bug修复或是添加新功能等；

3、开发完成后公布代码或直接在主网上发起更新提案（与此同时，呼吁开发方在完成开发后公布开发报告，详细介绍新合约的新特性，其中也应包括测试报告）；

4、从各节点中选拔出技术人员组成代码审计小组，对提案进行审计，也包括在测试网上进行测试，完成后向社区公布审计报告。提案更新完成后向该审计小组分发提案基金奖励；

5、各出块节点通过各种方式充分调查社区成员的意愿，达成共识；

6、若社区共识为通过，则各出块节点对新代码进行review，确保提交的代码和审计的代码一致，然后在review通过的基础上进行签名或通过该提案；

7、若签名或通过数达到15时，则各节点需向社区通告该提案已通过，并将于某某时间执行生效；

8、于某某时间执行该更新。

其中，对于

• 提高信息透明度，引力区将计划开发一个提案及信息公示网站bihuoniu.com，将最新的提案和相关信息公布给社群。另外引力区将建立提案专群，将社区里对提案参与度高的用户集中在一起，进行相关讨论。引力区也会在公众号、知识星球和快讯、引力观察里设立提案专区，会尽可能全地公布出提案，保持信息对称。

• 代表社区共识，引力区将建立引力核星群，吸纳对于社区管理，社区共识，社区利益最为关注，参与度也最高的社区成员加入，我们任何关于提案的共识，将首先在核星群里进行投票，然后根据结果进行最终决策。

• 更新代码审计，引力区将制定EOS代码守护者计划，招募一个代码审计小组，专门对于EOS的更新代码进行审计，测试，并形成一个标准流程。