图片12123132.png

Background

A couple of days ago, a proposal about RAM expansion was approved and applied by BPs including EOS Gravity to tackle the issue of overheated RAM price. It is a solution to increase RAM available on EOS from the current 64GB limit. It will increase EOS RAM gradually at 1kb per block.

However, during the execution of this proposal, the code updated on EOS mainnet contained an error parameter, leading to the first EOS RAM increase becoming 1.5 G.

Problems

This RAM expansion incident rang alarm bells in EOS community. As a BP participating in this proposal, we at EOS Gravity feel obliged to draw lessons and make actions. We think this incident exposed a number of problems in the process of system update proposal and we should get serious about them, especially when we tackle with proposals related to community members’ interests directly or indirectly.

1. Insufficient Disclosure

No sufficient related information disclosure when proposal was presented.
No sufficient related information disclosure when the code development completed.
No sufficient preparing time for community members before proposal was executed.

2. In What Ways Can Consensuses Be Reflected?

When a BP votes for a proposal, it should represent the consensus of its community members at the maximum level. Then how to ensure that?

3. Insufficient Code Audit

How to audit newly developed code? How to make sure there will be no big holes or back doors in the code? How to make timely and open information disclosure about the code to community members?

Suggestion

We suggest the current process of system update proposal should be optimized by improving information disclosure and making the process more parent to make sure BP could vote on behalf of its community members at the maximum level.

The suggested optimized process is as below:

B1 or BPs should come up with multiple solutions when they discuss on some bug or issues. When the discussion is about proposals related to community members’ interests directly or indirectly, a timely and open information disclosure should be made.
The party who presents a proposal, proposer for short, should develop the required new code, mainly including bug fix and new function adding.
The code should be published once completed or the proposer could propose the proposal on the mainnet directly. (Meanwhile, we appeal the proposer to publish a development report including features of the new contract and a test report once the development completed).
A code audit team should be organized with selected technicians from BPs. The team should conduct audit and test to the proposal, then publish an audit report. Once the proposal is executed, the team shall be rewarded by Worker Proposal Fund.
All BP should reach a consensus with their community members by listening to their voices to the full in multiple ways.
When the consensus is reached in the community, all BP should review the new code to make sure the submitted code is identical with the audited code. Only after this can the proposal be approved or signed by BPs.
When the BP poll or signatures reaches 15, all BP should make announcements to the community that the proposal has been approved and will be executed at a given time.
The proposal is executed at a given time.

What We Are Going to Do

1. Improve Information Transparency

EOS Gravity is planning to develop a proposal information disclosure website providing the latest related information to the community.
EOS Gravity will organize online chat groups for members who care about proposals, making sure proposals can be fully discussed by members.
EOS Gravity will open special columns for proposal-related information on a number of our We media channels to make sure proposal-related information are transparent and open.

2. Reach Community Consensus

EOS Gravity will organize online chat groups for members who are active to be a part of improving community governance and reaching community consensus. When a proposal is put forward, we will cast a vote in these groups first before making any terminal decisions.

3. Strengthen Code Audit

EOS Gravity is about to make a EOS Code Defender Plan by organizing a code audit team to develop a code audit process covering all links including audit and test.