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.
EOS Asia is starting to organize the EOS Code Academy where we will provide online training for developers to create DApps and take EOS mainstream.
Here you can find the very first EOS DApp development tutorial available online:
Current blockchains can be classified as either 1) un-permissioned (free-entry, limited rules governing complex behaviour, e.g. Bitcoin, Ethereum) or 2) permissioned (walled garden with central authority controlling access, strict rule-set, e.g. Ripple). With EOS we are building a Governed Blockchain that is a hybrid of the two, allowing free entry to a rules-based environment (for more on the Governed Blockchain see Ian Grigg’s video on YouTube, https://youtube.com/watch?v=qS5a_yS5NXo).
EOS Governance can be thought of as having three fundamental pillars:
There has been a lot of material shared, and subsequent debate, around how the Legislative and Executive function within EOS; leaving the Community understandably curious about the structure of the 3rd leg.
Following from the format for the Draft Constitution, this article presents the design goals behind the EOS Core Arbitration Forum. This will be the first of several articles discussing the Governance team’s suggested dispute-resolution structures and processes.
Agreement is not required. They are here so the reader can see the reasons for certain design choices. If you have different standards, goals, or principles, please state yours explicitly. That makes it clearer why we may disagree on any aspect.
An arbitration forum is an independent, impartial group of trained professionals who specialise in helping mutually-agreeing parties to resolve disputes outside of courts. In the off-chain world there are multiple examples of Arbitration Forums, such as the International Centre for Dispute Resolution (ICDR: www.icdr.org) or the London Court of International Arbitration (LCIA: www.lcia.org).
This begs the question, why create a dedicated EOS Arbitration Forum? Why not use an existing Arbitration Forum? We create a new forum, because blockchain adds a new context for arbitration. We do it because this new decentralized global platform for contractual agreement and value transfer bridges hundreds of jurisdictions. Having a single context -- one whose boundaries all participants can examine and agree upon before entry -- facilitates faster, cheaper, and fairer dispute resolution. In addition, existing off-chain Arbitration rule sets are not well adapted to handle some of the issues that will occur on a blockchain.
The EOS Core Arbitration Forum is a body that is composed of several parts:
To have an Arbitration Forum at launch we therefore need to have 1) Rules written, 2) Arbitrators appointed and, 3) Administrators in place.
Available at launch and authorised as part of Article III of the initial EOS Constitution
This means it can be voted out, other arbitration forums and rules added etc
Traditional arbitration systems normally focus on disputes that arise from an individual contract between two parties. In setting up an arbitration forum for EOS, we will need to broaden the scope of entities that are party to an arbitration. By doing this, the forum can cover a wider range of disputes - such as disputes between two parties that do not have a contract between them. In addition, EOS arbitration will need to consider activities such as Fraud, Theft, Defamation and violation of community norms (e.g. BP behaviour, prohibition on vote buying).
Arbitration will therefore need to consider disputes between:
The stated goal of Arbitration shall be to balance the power between the parties and result in a resolution that is as fair as possible, in the manner in which fairness is understood and expressed by the Constitution, laws, rules and customs of the community.
When a claim is made, it puts both the claimant and the respondent before the arbitrator. Therefore the arbitrator can find damages against the claimant if the claim is shown to be wrongful.
Similar to the EOS Constitution, the Core Arbitration Forum’s rules and procedures will be written in English. This does not mean, however, that Arbitrations should be conducted exclusively in English. Arbitrations may take place in the language that is most appropriate for the claimants and the case in question, as decided by the Arbitrator.
The goal is for a terse Arbitration rule-set that takes a common-sense approach and is easily understood by the community.
The next posts will dig further into the BIOS process for the Core Arbitration Forum, how Arbitrators are selected to the Forum, remedies Arbitrators may apply and, last but not least, the Arbitration principles.
(The opinions expressed in this post are my own and do not necessarily reflect those of any other entity.)
EDIT: Changed name to Core Arbitration Forum
By Katie Roman - EOS Go Writer
As decentralization begins to go mainstream, the crypto-community has to decide which blockchain technologies it will back and why; this article is an argument for the EOS blockchain and Delegated Proof of Stake.
When Dan Larimer (creator of the Bitshares, Steem, and the EOS blockchains) announced at the Inside Bitcoin Conference in Vegas in 2014 that mining was now obsolete, he did not endear himself to many that were in the crowd. This is because many of the people in attendance had made their fortunes mining cryptocurrency using the Proof of Work (POW) model. Unbeknownst to Larimer, that announcement sowed the seeds of a silent war; a war between those that wanted to ensure that the POW system continue to thrive, and those that wanted move on from an antiquated system to a superior one.
The writing was on the wall, so to speak, and the community would have to choose - would they go with POW or DPOS? The choice the crypto-community made then was one driven by fear and greed, but with the impending release of EOS the community has another chance, and this time their choice will shape the world’s view on blockchain technology forever.
A Quick Overview
If the crypto-community are to collectively make a choice, they have to understand what choice they are being asked to make. There are currently three important models in the industry that need to be considered: Proof-of-Work, Proof-of-Stake, and Delegated Proof-of-Stake (other systems will not be discussed in this article).
Bitcoin, Ethereum, and almost all cryptocurrencies out on the market today use the proof-of-work model. POW requires computers to “mine” cryptocurrency by solving complex mathematical problems aka decryption. For every problem these mining computers solve, they are rewarded with some cryptocurrency. Therefore, the cryptocurrency is the proof of their “work”. At the time this process was created, it was assumed that the computer power it takes to mine the coins would make it almost impossible to corrupt information on the blockchain due to the cost of the electricity the computers were using. This was an ingenious solution to possible attacks on the system, but as blockchain technology advanced, it became clear that the POW model was unsustainable and insufficient for the needs of the world at large.
As an alternative to POW, Proof-of-Stake was conceptualized by Sunny King and Scott Nadal in 2012. They had several goals centered around making mining more “green” and “fair”. Miners would be randomly chosen by the system, no energy would be wasted by having computers solved complicated math problems, and instead of mining, users could invest directly into the coins; they would not have to set-up and maintain expensive mining rigs. Just like in POW, it would be unreasonable for a user to commit a fraud attack on a proof-of-stake system, unless they would be able to steal more money than they would lose by forfeiting the sum of their deposits (which is unlikely).
Delegated Proof-of-Stake (DPOS), a method invented by Dan Larimer, resolves many of the problems seen in POW and POS systems. In a Delegated Proof-of-Stake system, a technological democracy is created by a community of block producers and staked users that agree to a certain set of rules.
Delegated Proof-of-Stake and Proof-of-Stake are two different animals; in a POS system, every wallet that contains coins is able to participate in process of validating transactions and forming consensus, thus the more coins in your wallet, the more coins you will eventually receive. With DPOS system every wallet that contains coins is able to vote for representatives. These representatives validate transactions and form consensus, and are paid for their efforts through the system. This avoids a pitfall of POS, which is that, just like in POW, consolidation will eventually occur.
Now that we have those simple definitions out of the way, let’s turn our attention back to Larimer, and DPOS.
The Rise of Centralization in Decentralization
Larimer knew what was coming; he knew that if blockchain based technologies were going to have a fighting chance in the real world POW was not the answer. He had the foresight to see that as cryptocurrency grew in popularity, more people with large sums of money would want to get into the game. As more people with more money entered the arena, they would push out smaller, less technologically advanced miners, and this would eventually lead to consolidation.
Consolidation is a no - no in the world of decentralization, and is especially repugnant to Larimer’s sensibilities. He knew he had to take action. While there were other options out there (POI, POS), they also had their problems, and both were prone to centralization. In 2014, Larimer published a paper on delegated-proof-of-stake; what he was proposing was radical - a blockchain based representative government.
Based on what we know of Larimer, we can assume that money is not his primary motivator; if it were, he could have made systems solely created to enrich himself, his family, and his friends. His disgust with centralization is due to the fact that centralization is a waste of resources; if a few hold all the coins, than the many will suffer. The promise of decentralization was that power would be more evenly distributed, and even small players could have a voice. However, the large amounts of money that started entering the blockchains sphere had attracted bad actors, and with the POW system, there was really nothing anyone could do about it. But Larimer saw the problem and he had a solution.
A Blockchain is Only As Good as Its Performance
While Larimer was philosophically driven, he was also practical. He knew people would not switch over to a DPOS system unless there were obvious benefits to using the DPOS system. POW had been used for a few years now, and there were obvious downsides; not only was it prone to centralization, but its technology was severely lacking. Due to the way POW is set-up, POW systems are often very SLOW, and the fees associated with such transactions are at worst prohibitive, and at best a very expensive nuisance. Because of these limitations, Larimer knew that POW would never catch on globally; blockchain would only be appealing to a niche group of (wealthy) people. But with so much money and power behind the POW system, Larimer knew the only way he could prove the superiority of DPOS was to build, so he built his first DPOS blockchain, Bitshares.
Bitshares was the first system to use DPOS, and the technological advantages were apparent right off the bat. Bitshares was far and away the fastest blockchain on the block, and was such a technological success that Larimer declared that mining, with all of its faults, was no longer needed.
Unfortunately that declaration caused panic among those that had significantly invested into the POW system; those with power never give up easily, and the industry rallied around a new up-and-coming blockchain called Ethereum (Ethereum uses POW). This industry wide snubbing of Bitshares was unfortunate, but not unexpected; radical change does not come easy. Fortunately, the system Larimer had created could not be ignored; as the system matured it was clear that DPOS was leaving POW in the dust.
The proof is in the numbers. As of today, Steem, Golos (a fork of Steem), and Bitshares process over half of all the industries transactions. Steem and Bitshares hold records for processing over a million of transactions a day, all without slowing down or using up large amounts of bandwidth. Meanwhile, Ethereum has hit a glass ceiling, struggling to support the meager amount of Dapps currently created in its environment, and Bitcoin can’t even see beyond the first floor. Blockchain developers that are smart have seen were POW will leave them, and have started to pivot to POS and DPOS systems.
EOS and the Growing Blockchain Community
So, this brings us to EOS. Just like Larimer’s previous projects, EOS will utilize a DPOS system. Using the knowledge he has accrued from the past, he plans to make EOS the most advanced DPOS system in the world. EOS will have no transaction fees, waste no resources (energy, currency, and otherwise), and will be built around an online, representative democracy. EOS, as an open source software, will be spread far and wide. It could be the genesis of a new future, and, for many, a new way of life.
It is up to us, the early adopters of blockchain technology to decide what message to send to the rest of the world. Do we want to back outdated, inferior technologies just because we fear change? Do we want to exploit people just learning about blockchain so that we can make money at their expense? Or do we want to seize the opportunity that is before us, and throw our time and money into a system that enriches the most, hurts the least, and empowers the many?
Make no mistake, the choices we make now will shape the future and how blockchains are perceived; the revolution will live or die by where we decide to stake our resources today. So please consider backing a DPOS blockchain, and more specifically EOS. Let’s show the world who we are, what we stand for, and what EOS can be - ground zero for a worldwide, crypto-led movement.
About the Author:
Katie Roman is an amateur paddle boarder and Dan Larimer fan girl. She lives in Central Oregon with her husband, son, and their rabbit Chestnut.
Who are we?
EOS Go is dedicated to uniting the EOS community towards launching EOS and beyond.
Software company block.one is creating EOS.IO and releasing it as open source code; thousands of individuals will need to come together to bring this new "internet of value" to life.
How to Get Involved:
Telegram - Forums - Community Announcements - Twitter - YouTube