As Block Producers inch closer to the launch of a single mainnet, interested members of the EOS Community have begun to ask questions. Many of those questions are related to the Worker Proposal process. In the spirit of asking questions, Thomas Cox recently reached out to the community to discuss the approach that the Worker Proposal team is following to design a Worker Proposal System and present it to the EOS community for adoption. Thomas released a short video here to announce this:
In the spirit of asking the right questions, the team that has coalesced around this project has framed its questions in a roadmap to help guide its thinking:
What is being built? How will it run? How will it run well? How will it keep running? How will its future usefulness be ensured? How will systemic abuse be prevented?
Using the roadmap, the team has begun asking deeper, more meaningful questions. Finding good answers to these questions will help us propose a system design to the community that works well and strengthens the EOS ecosystem.
The Worker Proposal Team is keen to open this discussion to the greater EOS community. To enable ongoing conversation with anyone interested in joining the discussion, a Telegram Group: EOSIO Worker Proposal System has been created and can be accessed here: https://t.me/joinchat/HK94zgwZVgyUdksD5siVww. The Telegram channel will be used for free-form discussion and early-phase ideation by members of the the Worker Proposal Team and members of the community.
In addition, the EOSGo Worker Proposal forum will be the system of record that will be used by the Worker Proposal team to formally communicate progress, request and gather community feedback, and present possible solutions; it will also be used by the community to formally submit ideas, escalate concerns, and provide material feedback. Join the conversation here: https://forums.eosgo.io/categories/worker-proposals
The following is an informal timeline that the Worker Proposal Team is targetting.
The Worker Proposal System is one of the most important pieces of the EOS puzzle, and it is one of the more difficult pieces to get right. We look forward to real, in-depth discussions with the community as we all work together to build a system that addresses the most important questions in a way that works.
Dan Larimer and I sat down together today (I mostly stood) for a lightning edit round on the default Constitution. (Some additional edits are here and will be covered in a separate posting.)
The revisions from that session are visible here:
This post is to give some context to the edits, and to share my recollection of what we said and the thinking behind specific changes.
The introductory remarks "This constitution is a multi-party contract..." is to make clear that the rest of the document is to be read as a contract between the Members.
You'll notice that the Articles weren't re-numbered fully, which actually makes the DIFF easier to read. This was fixed in a later pull request, so don't be surprised when the thing you were referring to as Article 15 later turns into Article 12.
Standard libertarian thinking here, and a useful catch-all in cases people have offered elsewhere about party X threatening party Y.
Changed wording to only prohibit false 'attestations' -- i.e. statements that you make that you explicitly tell others they can rely on as true. This reduces concerns about free speech becoming actionable, and reflects the 'CARS' approach from CACert, where one indicates which statements one is making as a 'reliable statement' that you're willing to be held liable for if other people rely on it being true.
Reworded to make it active voice ("Members grant...") and to acknowledge the case where a referendum might lead to a change of rules that lead to a change of property ownership.
Changed to plural 'Members' for parallel construction, and tightened wording.
Tightened wording and remove list.
Dan extended this based on significant input we've received from our lawyers, among other sources. Same purpose. Merges the old Articles V and VI, which several folks had requested.
Reworded from 'reversal of transactions' to the more generic 'restitution'.
Deleted as out of scope for the Constitution; these points are covered elsewhere.
Added 'free and open source' to this.
This article is still in flux.
Deleted as being too obvious to need stating.
Default changed from ECAF to ICC. Rationale has been explained by Moti on Telegram and (soon) on an EOS Go posting. ECAF work continues but ICC is the placeholder until token holders can amend this Article and elevate ECAF, if they choose to do so.
Removed list of subordinate documents.
Removed Malta. Going without a terrestrial fallback.
This latest version of the Constitution has replaced the EOS Core Arbitration Forum (ECAF) with a new default Arbitration forum; the International Court of Arbitration of the International Chamber of Commerce (ICC). You can see all the changes to the Constitution here: https://github.com/EOSIO/eos/commit/ab30b771efa8d5efda3f6746ebe55a2e59085fdf#diff-3e7c13a8ffaa6d097827c0124007e558
With the launch of the Main Net quickly approaching, it was felt that the ECAF would not have the authority and capability to fully function as the default Arbitration Forum for the following reasons:
To ensure that there is a viable, default Arbitration Forum available at launch, the ICC has been selected.
The ICC is an international business organisation whose Arbitration services are widely accepted for the resolution of international disputes.
The ICC's Arbitration rules share some similarities to the ECAF's proposed ruleset. More details on the ICC's International Court of Arbitration and its Rules for dispute resolution can be found here and here.
While the ICC does not have experience of arbitrating blockchain disputes (and to my knowledge no Arbitration Forum has), it does have vast experience in arbitrating complex, international, commercial disputes.
The ECAF will continue developing an Arbitration forum for the EOS Community by the Community. Once the ECAF's arbitral capabilities have matured, the intention is to seek a mandate from the Community (via a referendum) to change the default forum from the ICC to the ECAF.
Yes. With this change, the ICC is the default and senior forum. However developers are free to name the ECAF (or any other Arbitration Forum) as their preferred Forum in their smart contracts. Should they do so, the ICC will serve as a forum for appeal.
As previously discussed in the Design Principles of this Draft, the EOSIO Software will provide a mechanism for Token Holders electing Block Producers. Voting will be by weight of staked tokens as detailed elsewhere.
No Member shall offer nor accept anything of value in exchange for a vote of any type, including for Block Producer candidates, Amendments or Worker Proposals, nor shall any Member unduly influence the vote of another.
Votes represent a public good. When a token holder takes the time to become informed and cast a wise vote, the whole chain benefits from this effort.
03-May-2018: reworded article from old:
Renamed article from 'No Buying or Selling of Votes' to 'Voter Independence'
Laws and agreements must be enforced and enforceable. This article states that the Member agrees to face penalties if found to have violated the rules. This prevents someone from escaping responsibility via a claim that they didn't agree to follow the rules or shoulder the consequences of a violation. It also normalizes the community around what penalties we may assess on one another via our systems of collective action.
Each Member agrees that penalties for violations may include, but are not limited to, fines, account freezing, and reversal of transactions.
This clause is a simple one. It states explicitly what was made implicit in earlier articles of this same Constitution, i.e. that the rules can be enforced and that a Member faces -- and agrees to face -- punishment for breaking the group's rules. The method of punishment is set out by the Arbitrator in their particular case at hand.
There should probably be a community document in which "standard" penalties are set forth for typical transgressions. That document should not be part of the Constitution, and will likely evolve as the community does.
This article authorizes a governance document, the Block Producer Agreement. It's intended to be a take-it-or-leave-it offer by the Members acting collectively and setting out what those Members want each Block Producer to do (and refrain from doing).
No Member shall serve as a Block Producer who has not agreed in advance to the Block Producer Agreement provided by the Members of this blockchain.
The Constitution is intended to be as brief as possible, and the Block Producer Agreement is potentially detailed. For that reason it was decided to separate that Agreement into its own document.
If the Constitution did not contain this Article, then the BP Agreement would be at best a nice-to-have rather than a must-have aspect of Governance.
It seems likely that Block Producers, seeking to signal their trustworthiness and attract votes, may agree to the Block Producer Agreement and also undertake additional promises. There's nothing wrong with BPs seeking to embrace a higher standard than whatever may be found in the Block Producer Agreement.
The method of agreeing is not specified. It's likely that the Ricardian Contract for the "RegProducer" system command, by which a Member registers themselves as a BP candidate, will include the BP Agreement by reference. If so, then the act of registering as a BP candidate will entail agreeing to the BP Agreement. If true, one might think this Article superfluous. But that is not so -- this Article raises the BP Agreement's status from a mere Contract to a Governing document co-equal to the Constitution itself. This gives the BP Agreement greater standing in cases of Arbitration; specifically, the BP Agreement like the Constitution overrule any Contract, should they be in conflict.
A link to the latest Block Producer Agreement should go here once it is published.
26-Apr-2018: added link to EOS New York Code of Conduct in the References section.
27-Apr-2018: added link to EOS BlockSmith Independence and Integrity Pledge in the References section.
I got the following questions regarding memory and storage:
1) I am running a node. I am not a block producer. What is stored in my filesystem and what kind of database or system is used?
2) When I compile a smart contract and push it, is the code stored in a transaction and therefore in a block?
3) When I use a database or table inside my contract, is it stored in RAM of a block producer? Where does the database go when this producer shuts down?
4) Where are accounts stored?
5) How does IPFS come into play? What is stored there? Where is the mongoDB and what is inside?
Hopefully this questions are easy to understand. Could you also provide a resource of your answer (some post or documentation page).
Goal: Introduce ideas for improving EOS legislation with a "Houses" model.
In this video at about 02:00, @thomasbcox refers to voting by token holders as the Legislative Branch of EOS governance.
He discusses the possibility of having different "Houses". I think such a model would greatly benefit EOS's long-term success.
Problems with having one single procedure for funding and/or referendums:
1) Voter apathy. There's a lot to keep track of. With a monolothic process, many issues and ideas can get lost in the noise.
2) Without side-by-side systems, there is no basis for comparison, critique, and improvement. Having different procedures and/or different groups completing similar work generates a lot of useful data.
What is a legislative "House"?
A separate body of the legislative government. Usually, legislatives are Uni-, Bi-, or Tricameral. There are usually two rationales given. First is a check and balance on the other house.
"A formidable sinister interest may always obtain the complete command of a dominant assembly by some chance and for a moment, and it is therefore of great use to have a second chamber of an opposite sort, differently composed, in which that interest in all likelihood will not rule." — Walter Bagehot, 19th century British essayist
The second rationale, is the empowering of different interest groups. The U.S. Senate, before the 17th Amendment, represented the interests of State governments, and the U.S. House of Representatives represented the interests of the people.
Why use a system of Houses?
Houses help solve both problems listed above.
1) It is easier to take initiative for people who are in smaller groups.
2) The different cultures and processes that evolve in different houses will be a great basis for comparison and improvement.
3) Arbiters or devs are critical to the eco-system, but without their own house, they risk losing their voice.
What Houses should we have?
One for every identifiable group in the eco-system, and we should create new houses when new interest groups arise.
General House - This can be the standard proposal process as outlined elsewhere. It mimicks the process used by Dash. We can hedge against the failure of this experiment by routing a vast majority of WP funds through this process.
House of Commons - The idea here is to have a low bar of entry for proposals. Fees are low and/or refundable. Proposals will be plentiful.
House of Lords - Voting here requires a high reputation score. Fees are high and non-refundable. Proposals will be few, but they'll get a lot of attention.
House of Devs - For developers who've crossed a certain threshold of contributions.
House of Dapps - For the owners of smart contracts which exceed a threshold of usage.
House of Judges - Arbiters will have unique problems and unique perspectives. Great things might happen if we give them their own channel for fudning projects. Since they are a separate branch of government, maybe they should not be able to propose governance changes through this house.
House of BPs - Since BPs have their own funding, maybe they should not be able to propose projects through this house, only governance amendements and feature requests.
How might voting work?
The document "States and Timeline for Project Proposals" is a basis of comparison. https://docs.google.com/drawings/d/1wpaVp4WuiGsCnRCqsrIeziF5RpUImTuv5t_jVAlgaeQ
Every House can develop its own process to reach the "Final Proposal" state.
If a House is proposing a project and operating inside of its allocated budget, then we can lower the standard of approval from 10% yes / 5% quorum. Another idea is consider the project approved, but give other houses veto power.
For Governance Changes:
We should probably be more careful with governance changes.
Comments and criticisms welcome. I'd be especially curious to hear the comments of anyone familiar with BitShares's legislative problems.