Press
Block.one’s Proposal for EOS Constitution v2.0
The EOS community has embarked on a revolutionary journey to combine the best aspects of crypto-contracts, human contracts, and human dispute resolution. This makes EOS the first smart Ricardian Contract blockchain.
The decentralized birth of a new public blockchain and governance system is fundamentally challenging because everyone is trying to figure out the rules. Some people want to replicate existing legal structures, others want to regulate all manner of behavior, while others want to retain Code-is-Law. Block.one has watched the community launch an EOSIO-based blockchain, and has learned important lessons from the experience.
The Importance of Code-is-Law
The single most compelling feature of Code-is-Law is the removal of any room for dispute. All contractual terms are expressed in the code, which will execute predictably for all parties in the absence of bugs or extraordinary situations.
EOSIO, however, was created with the recognition that bugs/extraordinary events will happen and that the community needs a process to establish the intent of the smart contracts in order to quickly resolve issues in a transparent and predictable way, when they do occur.
Ricardian Contracts and Enforcing Subjective Terms
A Ricardian Contract specifies both free-form terms as well as terms implemented in code. The EOS community is currently debating if and how to enforce the free-from terms. These terms include provisions like required disclosure of block producer ownership and certification of facts under penalty of perjury. Some want more terms to expand this type of regulation.
The purpose of the Ricardian contracts is to document the intent of the parties and provide evidence of intent in the event of a bug in the code. If a Ricardian contract includes terms that cannot possibly be evaluated and enforced by the code, then it is outside the jurisdiction of the block producers and protocol-level community arbitration to evaluate and enforce.
A properly written Ricardian contract is entirely enforced by code; therefore, the only disputes that should arise relate to bugs in the code, which can and should be resolved by fixing the code. If a Ricardian contract wants to enforce other terms (e.g. perjury), then it must do so by defining the process in code for submitting grievances, appointing judges, collecting bond payments, and rendering decisions, and enforcing them. All of this should happen at the application layer, not at the base protocol layer. The entire enforcement process should be objective with all actors exercising complete autonomy within the limits of the intent of the code.
A Need for Objective Boundaries
Users of any blockchain need some guarantees from the community in order to feel safe and secure. If everything on the blockchain is subject to majority opinion, then an unreasonable amount of predictability is lost. Further, if the community does not have strong, objective, organizing principles, then everything is subject to interpretation and becomes unacceptably arbitrary.
Therefore, Block.one suggests ending all protocol-level arbitration orders other than to render non-binding opinions on the intent of the code. We believe the elected block producers should be the jury, and must render a 2/3+1 decision to alter a broken contract. Generally speaking, the only contact that producers should be fixing is the system contract (the one that manages the core token, staking, resources, and voting). Contract developers have the ability and should define their own processes for fixing bugs and updating their own contracts.
This means that the elected block producers have the same power as demonstrated by the large mining pools in previous instances of intervention, such as the DAO hack. With EOSIO software, this intervention process can be formalized and is ultimately in the hands of the token voters rather than being informal and in the hands of hash power voters.
Lost & Stolen Keys
The purpose of private keys is to generate objective proof-of-ownership. If the network cannot rely on signatures alone, then it must rely upon identity and subjective interpretations of intent. This is not feasible as it will open up an unsustainable level of disputes and new kinds of fraud and/or injustice.
The solution to this problem should be technical in nature: implement multisig with biometric protection of hardware wallets with time delays. Each member of the community is responsible for their own security and permissions configuration. Enabling a fall-back to arbitration to dispute the validity of a signature after it has been irreversibly accepted by the blockchain opens up more issues than it solves. EOSIO was designed with support for Apple Secure Enclave, Touch ID, Face ID, and time delays. Once deployed in wallets, stealing private keys should be virtually unheard of and time delays should handle the rest.
EOSIO was written from the ground up to provide the infrastructure required to truly protect and recover accounts on an opt-in basis. These features include support for the R1 elliptic curve as used by Apple, Android, and many smart card devices. With time delays, users can enjoy the ease-of-use of signing with a single-device while having a secure backup of multi-device signatures. The ability to objectively read account inactivity time in smart contracts gives developers the ability to define their own recovery processes without giving a 3rd party control until they are inactive.
How to Enforce Arbitration Orders for Stolen Private Keys
There are different ways to protect against fraud and private key theft. One way is to opt-in to a banking Ricardian contract that controls the tokens on behalf of owners. Transfers within the smart contract are subject to dispute resolution where the contract-appointed arbitrators have the power to reverse transactions and freeze tokens. Withdrawals from the banking smart contract are subject to a three-day (or longer) delay, after which they cannot be reversed.
Those who want the elected block producers and/or ECAF to protect their interests could opt-in to a new smart contract where ECAF/producers are the arbitration system. Exchanges that want to interact with these customers on a faster-than-three-day delay basis can also open a deposit account within the banking smart contract. The scope of arbitrator power would be limited to that contract alone.
Some people are worried about their entire account being stolen, not just their tokens. This situation can be resolved by placing the entire account under the ownership of a smart contract. As a user of the account, you would control the active keys, but you would not directly control the owner permission.
EOSIO is designed with all the tools and capabilities to build robust high-level governance for those who would prefer to trust an organization like ECAF to arbitrate disputes over stolen keys. There may eventually be hundreds of such organizations, each operating on different principles, all built on the same EOSIO-based blockchain.
Block.one’s supported EOS Constitution v2.0
As explained above, the intent of Code-is-Law where intent is documented by code, Ricardian Contract, user interfaces, and actual use.
- If there is a dispute on intent of code, then intent shall be determined by a super majority vote of elected producers or an arbiter mutually agreed to by the parties to the dispute and enacted by producers. A super majority may, at their discretion, freeze a 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 producers may charge a reasonable fee and/or place other reasonable requirements on the parties to the dispute. 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 producers authority to evaluate and enforce.
- Block producers shall not freeze or modify contracts that are operating as intended.
- Contract developers are not liable for damages caused by unintentional bugs in the code. All Parties are responsible for auditing the code and the Ricardian contract before use.
- All service providers who produce tools to facilitate the construction and signing of transactions on behalf of others shall present the full Ricardian Contract terms of this Constitution and other referenced contracts.
- No Party shall have a fiduciary responsibility to support the value of the EOS token. The Parties do not authorize anyone to hold assets, borrow, speak, nor contract on behalf of EOS token holders or the blockchain collectively. This blockchain shall have no owners, managers, or fiduciaries.
- A Ricardian Contract is deemed accepted when a transaction based on that contract is incorporated into the blockchain.
- Parties voluntarily consent for all other Parties to permanently and irrevocably retain, copy, analyze, and distribute all broadcast transactions and derivative information.
- Use of the blockchain shall constitute consent to its terms.
- This Constitution may be amended by a vote of the EOS token holders that attracts no less than 15% staked vote participation among tokens and no fewer than 10% more Yes votes than No votes, sustained for 30 continuous days within a 120 day period.
Important Note: All material is provided subject to this important notice and you must familiarize yourself with its terms. The notice contains important information, limitations, and restrictions relating to our software, publications, trademarks, third-party resources and forward-looking statements. By accessing any of our material, you accept and agree to the terms of the notice.