EOS Alliance | Constitution Referendum Series | Summary | Week 7 | English Only
Recap of the Alliance open calls from Week 7, as interpreted by Martin Breuer (EOS Nation, Regional Director)
After missing out on some calls due to my travels back to China, I’ll continue summaries of the EOS Alliance Constitution Referendum Series with the “English Only” Call of Week #7.
While previous weeks were mainly about comparing and analyzing the currently proposed constitutions, the task for week #7 was to draft a 1st Article for a potentially new proposal.
The first article should represent the most important ideas, values and spirit of the overall document.
Before i start my summary, I want to mention the KOR/ENG Call of Week # 7, which motivated the group to draft an entire Version 3 Constitution, which is currently still being reviewed. You can find it here.
Also, I wanted to mention a very useful spreadsheet to compare the different Constitution Versions. It was done by EOS Amsterdam while they were presenting their Version 3 proposal. You can find it here.
So The “English Only” Call of week #7 started on October 5th 5:30 am Beijing time which was quite early for me, so I want to thank EOS Detroit for their Live Stream recording. They can all be found on their YouTube channel.
Participation of week 6 was a bit low, but since some well known and opinionated people joined it got quite interesting. One of the participants was Perry Sienas who recently wrote articles about the current state of EOS and his suggestions. You can find the articles here.
The call quickly developed into a more general discussion on:
What would be the scope of the constitution and on which values could the community agree upon?
During the call, a lot of interesting points were made and I’ll try my best to summarize those findings, questions and suggestions in the following:
- The group agreed on safeguards being essential and a key to mass adoption, in general, the discussion was about where and how these safeguards need to be implemented. Should those safeguards be placed on the EOS base layer or at the Dapp layer?
- Article 1 in v1 puts all Dispute Resolution in form of ECAF on the Base Layer, whereas in the v2 arbitration would only come into action when the code has flaws and needs to be changed according to its intent as written in the Ricardian Contract.
- Perry wishes to define the Base Layer as simple as possible. Apps built on top of the Base Layer then would write their own constitutions catering to their specific wishes and needs. In this case, the Base Layer could be compared to the HTTP Protocol. The EOS Base Layer arbitration would be limited to the intent of code as law defined thru Ricardian contracts. User protection would be implemented on the Application Layer. Based on this model comparing EOS to the current internet model would result in Base Layer: HTTP (Infrastructure) & App Layer: i.e. Paypal (Protection)
- A simple Base Layer would ensure the maximum of scalability, which is one of the major promises of EOS. However, having arbitration in case of disputes is another prominent feature in the original design of EOS.io.
- Would shifting Dispute Resolution for users to the app layer mean simply shifting the current problems to a different place or is the dApp layer just the better place to solve the issues?
- Should human and social activity be mainly happening on the dApp layer? Many voices in the community think subjective terms on base layer should be minimized to avoid unnecessary workload on that layer.
- Does V2 Article 1 protect from a scam? If the Intent of Code is stealing money, there is no actual flaw in the code, that could entitle arbitrators to act. How can we, in this case, protect users? A “scammy dApp” might not be compliant, to begin with, i.e. they wouldn’t provide a Ricardian Contract.
- To avoid scammy applications a vetting process similar to the apple app store would be useful. However, this would go against the “Everyone can build on EOS” and anti-censorship spirit.
Here I personally want to mention the winner of the London Hackathon EOS Shield which might already have an idea for a structure that can provide a more secure environment for Devs and Users. See their winning pitch here. It was not mentioned in the call, but i think it’s a good example, in this place.
- Arbitration on the Base Layer would be manual in the beginning but later mainly be automated. Could these automated processes create a service for applications at some point?
- Base layer dispute resolution would be a “catch-all” approach whereas dispute resolution on dApp layer would cause much specialization, which could potentially cause chaos since there are multiple constitutions and rule systems on multiple applications.
- Would “Grandma” interact with the Base Layer or with her favorite dApps on EOS? Where does she really need protection?
- Todor differentiates “Grandma user ” to “Grandma business owner”. Without a human layer at the bottom, there’s no way of risk assessment for insurances, which is one of the reasons why many businesses feel insecure building on the blockchain.
- Would businesses launch on dApps or on the Base Layer?
- Currently, EOS is used for all kinds of interactions, but later apps will have their own tokens with their own governance system and use case. EOS then will be mainly used to trade network resources. In that case, won’t most users interact with the dApps Layer mostly anyway and therefore user protection should be placed there?
- The group agrees that there needs to be a way to enforce rules on the base layer in case there is something going wrong. If this needs to be done by “arbitration” and via a “Constitution” needs to be discussed. EOS can be viewed as a service provider, which in the real world has “Terms of use” and an attached organization that deals with abuse of such terms.
- EOS Amsterdams Article 1 in their proposed version 3 mentions “Good Faith” which would also be a subjective term. Is total objectivity (as in BTC or ETH) possible on EOS or is this kind of immutability an illusion in a DPOS system because ultimately humans validate the transactions.
- Amsterdam’s proposal is missing separation of powers, because BPs would judge and also execute.
- A balanced separation of powers would suggest BPs as executive power, community via voting/referendum as legislative power and a 3rd body for the judicial power.
- An independent non-affiliated arbitration group as 3rd power is needed, how this group would be elected or appointed still needs to be figured out.
- This 3rd body would need to be financed by a general fund instead of fees (paid by the user), to avoid selective treatment of cases.
- Would it make sense to have a separate document for design values?
I hope I managed to distill the major points of the discussion correctly.
You can find the recording of the call here.
At the end of the call the groups draft for Article 1 resulted in:
“If there’s a dispute on intend of code, then intent shall be determined by a (judicial party / third head in balance of power) mutually agreed to by the parties to the dispute and enacted by producers. This (judicial party) may, at their discretion, issue an order to freeze an contract during an active dispute until such time as code to fix the contract is available. The parties to the dispute must produce proposed replacement code.
The blockchain commons fund will compensate the judicial body. Block producers may execute an order from the (judicial body) with a super majority is defined as 2/3+1.
Ricardian contractual terms that cannot be enforced by properly functioning code are beyond the scope of the (judicial body) authority to evaluate and enforce.”
Thanks for reading.
Find all future EOS Alliance events and calls HERE.
See you on the calls | Martin Breuer
