Hello EOS!
This write up is my humble attempt to start a more formal and open EOS community discussion on the recent events surrounding the SX Vault hack. More specifically this looks at the actions taken by EOS BPs to resolve the event and how access to those actions should be more widely available.
I will do my best to keep this short, but for you skim readers the headings and bulleted TLDRs can get you to the point.
Also please keep in mind that Eden on EOS is still very new! Anything I’m suggesting here is based on many more trial elections taking place and proving, among other things, that selecting for merit and trust are prevailing attributes of those who make it to the top.
Introduction
-
EOS is awesome
-
Governance is better when merit counts
EOS has an opportunity to be the first blockchain to utilize the Eden political playoff system, which was invented by Daniel Larimer and described in his book More Equal Animals. Unlike traditional crypto quasi-governance entities (e.g. Bitcoin Foundation, Ethereum Foundation, Cardano Foundation) Eden on EOS can easily engage, identify, and promote its most dedicated and deserving community members to positions of influence. This meritocratic system levels the playing field by removing many of the advantages gained by deep pockets and difficult to obtain strategic relationships.
As Eden grows it’s members will represent an increasing percentage of the EOS community’s entire population. Eventually, more Eden groups will form around languages other than English, and this network effect will transform “Eden on EOS” into a truly global community of communities, or democracy of democracies.
What Can Eden Do?
-
Eden selects for trusted individuals from within the community
-
The Eden Board is trusted to judge on “intent of code” disputes
The more one learns about cryptocurrencies the more one realizes this is a revolution on many fronts. It is not just some nerdy, overly technical internet money, but an emergent voluntary global community. EOS still has the best tech but has struggled with the formation of its community, until now! Eden represents an opportunity for the EOS community, where whales and plebs have equal power, to arrive at consensus on not only what path project funding on EOS should take, but how a layer of trusted humans can be utilized in governance. Eden is an opportunity to reallocate the power of EOS back into the hands of the community members themselves and away from those that simply profit without giving back to the chain and token holders alike.
If we can agree that the majority of Eden members want what is best for EOS, we can then reasonably conclude (by trusting the Eden system) that most of the final round elected Eden members (the “Board”) will make decisions that are in the best interest of EOS and the EOS community as a whole. I understand this is a leap for some, as we are now trusting a novel process to identify and promote individuals that are to be “trusted.” Blockchains after all are often designed to be deliberately “trustless” so this might seem quite counterintuitive. The issue of course can be boiled down to the debate of “code is law” vs “intent of code is law.” Without passing judgement as to which of these two options is ideal, what I will say is EOS was designed and launched with “intent of code” being the dominant perspective. This was indicated by the initial constitution and creation of the EOSIO Core Arbitration Forum (ECAF).
The missing piece required to properly integrate the “intent of code is law” perspective is deciding who exactly gets to judge the intent. I, and many others, would suggest that the Eden process solves this. Those that make it to the Board after each Eden election playoff are trusted by the community such that if put in a position to arbitrate on an intent of code dispute, these individuals will pass the correct judgement. Therefore, they will do what is best for EOS and the entire EOS community.
Focusing on a Quick Win
-
Win-win outcomes with aligned incentives are ideal
-
Change should be minimal and deliberately gradual
-
We need a new deal between BPs and the community to allow for equal access to BP “god powers”
Part of my success in the first mock Eden election was focusing on the idea of getting a quick win, with a measurable outcome to define victory (Note: victory doesn’t need to be one-sided. The best victories are when all parties involved “win”). I will use that same strategy here. If we really want the BPs in control of the chain to accept any type of proposal that curtails their “god powers” we need to focus on keeping things simple. So simple in fact that it would require minimal coding and minimal changes to the status quo.
We all know about “change” and how it can be difficult to achieve. This especially if the final goal is radically different from where we are today. Therefore, in order to achieve great things, that involve substantial change, we are wise to target incremental progress along this path. There are many benefits to this approach, one being we actually might get somewhere. Another is that our current goal might not be ideal. Without focusing on gradual change, we lose opportunities to correct course and improve upon what that final outcome becomes.
I would suggest it is time for a new deal between the EOS community and the BPs that operate the EOS blockchain. This deal could be considered a “Peace Treaty” as explained in Dan’s book. This treaty should lay out the expectations of the community as to why, when, and how the BPs use their “god power” to influence the chain. The treaty would include details on who in the Community can access these powers, but more importantly how they can be accessed. We must ensure exploit and hack recovery are granted to as many dApp developers as possible. This will lead to a levelling of the playing field so that all EOS dApps, big and small, have an opt-in solution to resolving exploits and hacks that were previously only available to the well connected .
A Peace Treaty
The following example is a system that could be outlined in a potential Peace Treaty between accepting BPs and the EOS Community.
What if we create a solution that is opt-in for BPs and dApps alike? This system would include a fee mechanism for arbitration services when they are requested? The fee will prevent spamming this service and provide fair compensation for the time of those involved (BPs, trusted experts, and Eden members) to deal with the issue and bring it to resolution. The Eden Board is trusted to judge the intent of code dispute and then approve the BP’s use of their “god powers.” BPs would agree to never use these powers unless “Eden” approves it (Note: Eden here is loosely defined since ideally this would be a group of Edens collectively working together on these adjudications and not just the English one). The deliberations of the Eden Board(s) are publicly recorded no different than the elections themselves. The Eden Board(s) would need to achieve the same 2/3+1 vote to approve any action. For example, change account keys, move tokens within accounts, or whatever else these “god powers” may permit. The fee for services needs to be large enough to incentivise BPs, material experts, and Eden Board members to respond in a timely manner. The Eden Board members could make it known in advance what their intentions would be with the funds received from these services (i.e. donate it back to Eden for future round funding, or a hybrid with some compensation for time and inconvenience with excess donated).
The following is an example workflow of this process:
Set up:
-
A Peace Treaty is created with clear terms and rules of engagement. This includes details on how dApps can access these services and commitments from BPs on responsiveness when requested.
-
BPs signal their acceptance of the Peace Treaty. This becomes another metric used by the Eden voter proxy (and others) to consider when voting for BPs as not all will accept this deal.
-
dApps indicate to their users and signal to the BPs that they are participating and have opted-in to this deal. This should include an approval check from Eden that the dApp contracts have passed a trusted security audit. dApp users therefore agree that in the event of a hack/exploit, it is possible that some dApp functions will be halted, or related accounts that interact with the dApp may be temporarily affected (e.g. tokens frozen).
A hack occurs:
-
The affected dApp sends a signal to the BPs that a hack has occurred and submits a request for BPs to initiate atypical emergency actions. The format of this submission should be predefined. It would include, among other things, any details of the exploit/hack, the requested temporary action, the desired final outcome of this request, and if accounts are to be frozen the details needed to do that are also provided (e.g. account names with proof of theft/fraud). This signal should be accompanied by a bond to prevent spamming the BPs with false claims. The greater the severity of the claim, and the larger the number of affected accounts, the larger the required bond. The larger the bond the faster it is expected the BPs will act and can be detailed in the treaty. This bond could for example be a dApp’s “risk reserve” account.
-
Any action taken by the BPs at this stage is only temporary until the situation is reviewed by “Eden.”
Eden called to arbitrate:
-
A signal is sent to Eden from the BPs that their services are requested to review a claim.
-
The Eden Board members, as part of their duties, agree to be available within a certain time-frame to adjudicate claims. They can signal their availability and if a member of a Board is unavailable (planned or non-responsive) a random member from the playoff tier below the Board can be randomly selected to fill in. This tier of members will also signal their availability for urgent requests.
-
The Eden Board will assemble on a live recorded call with representatives from the BPs, the affected dApp, any material experts, and the defendant (if available).
-
The Eden Board must come to a 2/3+1 vote to permit the requested use of BP “god powers” to resolve the issue.
-
The fee schedule for these services should be known in advance. Any overpayment from the bond will be returned to the dApp owner(s) regardless of the outcome. BPs, material experts, and Eden retain their portion for services rendered.
Governance as a Service
Eden can be leveraged to provide many governance related services to the EOS Community. The funding of Eden could be used to build the following products and services:
-
Security tools for dApps that will decrease the likelihood of needing to request BP intervention (i.e. automated sanity check and signalling apps, secure withdrawal contracts with and without time-delays etc…)
-
Auditing services from an approved list of auditors.
-
A trusted list of security experts to support hack/exploit investigations.
-
Ricardian Contract review and support to ensure these are up to date and accurate.
-
Education services for dApp developers and users to understand the risks associated with smart contracts.
-
Applications that support the dApp submissions of exploits/hacks to BPs. This will streamline communications between dApps and BPs thereby facilitating faster and more accurate responses from BPs to temporarily mitigate any further damages.
-
An insurance product could be created for users and dApp owners to insure against potential losses.
-
An Eden Proxy can be created that will select BPs based on a fixed scoring/ranking system. This ranking system can be updated similar to Eden Bylaws.
That’s all I got… again this is just a set of suggestions to start a conversation. I expect much, if not all of this will be improved upon or removed and replaced entirely with a better proposal. Regardless, we need to come together as a community and have our voices heard. We need to make it clear that we are not ok with unequal access to special privileges by a select few.
We should strive to become more equal animals and amplify our power where 1+1=3.
Go EOS!!!
Chris