1 / 42

Governance and open source public blockchain networks

Governance and open source public blockchain networks. “We have elected to put our money and faith in a mathematical framework that is free of politics and human error.” -Tyler Winklevoss “No Leaders, No Rulers, in Code we Trust” -Satoshi Roundtable. Governance:.

grantm
Download Presentation

Governance and open source public blockchain networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Governance and open source public blockchain networks “We have elected to put our money and faith in a mathematical framework that is free of politics and human error.” -Tyler Winklevoss “No Leaders, No Rulers, in Code we Trust” -Satoshi Roundtable

  2. Governance: • The processes of interaction and decision-making among the actors involved in a collective problem that lead to the creation, reinforcement, or reproduction of social norms and institutions • Prof. Lawrence Lessig: laws, architecture, especially norms and (infrequently) markets • Government:  an organization that has both the responsibility and authority to make binding decisions in a given geopolitical system by establishing laws • Politics: means by which groups of people reach collective decisions that are binding and enforceable upon the group

  3. Governance: • “Good” and “Bad” governance is inherently subjective • Democracy/ Theocracy/ Monarchy/ Oligarchy/ Republic • Direct/ Representative /Non-participatory • May be measured across a spectrum by assessing characteristics • Predictability, reliability, consistency, bias, self interest, transparency, corruption, accountability, effectiveness, trustworthiness, honesty, efficiency • Governance may arise in a variety of ways

  4. Governance of Cryptoasset Networks: • Governance is the key determinant of the features and function of a given crypto asset system • Technical Control • Consensus mechanism • Codebase control • Political control • Transactional control

  5. Open Source Software • Open source: “source code” (human readable code) is publicly available • Corporate open source: open source but company decides direction of development. Example: Red Hat Linux • “Grassroots” open source: self spawned, non- sponsored voluntary software development • Linus’ Law: "given enough eyeballs, all bugs are shallow” • Typically distributed under a license agreement that allows software to be redistributed, modified, sometimes sold. • Typically disclaim all rights/responsibilities, liability, “As Is Where Is”

  6. Crypto governance and system function • Public networks using proof of work prioritize “censorship resistance” and maintaining “immutability” • How “immutable” is any given blockchain’s ledger of transactions? • How “censorship resistant” is any given system? • Consider the impact of theDao on Ethereum

  7. Who “controls” public crypto systems? • Developers? • Core Developers? • Miners? • Node operators? • Founders? • Exchanges? • Social Influencers?

  8. Why does this control matter? • What are the risks? • 1) the risk of impeded decision-making about changes to the software code • 2) the risk that the software is inadequately maintained due to insufficient or problematic funding for software development and maintenance • 3) the risk of inefficient or non-altruistic emergency response. • 4) the risk that the software (and the blockchain and other structures built on it) forks • How are these risks averted?

  9. Open Source Forks • Forks- modifying prior existing code so it is prospectively distinct from the existing codebase in a network • Assumptions- longest chain governs, shorter chains are orphans, to be abandoned • Reality- doesn’t always work that way- ETC, BCH • Dissenters may maintain their prior state of the network. Why? • Seiniorage • Philosophy • Control the direction of the project • Different because they purport to include value and be “truth” • What is “Bitcoin”? • If it forks 3x, and the original code is not being used, which is “bitcoin”? • What if many key developers change projects? • Who controls the “ticker” for Bitcoin?

  10. Who should be responsible for controlling open source public crypto systems? • Should anyone “be responsible” at all? • What tools should be used? • Political choices (immutable?) • Marketing choices (messaging/advertising?) • Technical Choices (write code with fail safes/backdoors?) • Regulatory Choices (write code to comply with law?) • Who decides a crisis meriting a response? • Who, if anyone, would be appropriate to respond? • Should the “responders” be liable for acting/failing to act? • From where do “responders” derive their authority?

  11. Corporate Governance • Compare to legally recognized corporate governance • Directors, officers have expressly defined authority • Authority derived from statute and caselaw • Grant of power to allow the entity to assert individual legal existence is balanced against responsibilities owed to the entity and fiduciary duties owed to certain others

  12. Fundamental principles of corporate law: • “The business and affairs of every corporation organized under this chapter shall be managed by or under the direction of a board of directors….” (DGCL §141(a)) • Directors serve as agents to the owners of the corporation (i.e. shareholders) • Directors do not directly manage the business of the company, but they are ultimately responsible for the management of the corporation • The Board discharges its duties by appointing and supervising officers who run the day-to-day operations • Officers are subject to the same duties as directors • The Board should be informed about the business, including results of operations, and should understand the company’s strategies and corporate plans • The Board should be involved in and approve major decisions for the corporations (such as entering into significant transactions)

  13. Duty of Care • The duty to make careful, informed decisions by assuming an active role throughout the entire decision-making process. See § 607.0830, Fla. Stat. (2018). In so doing, directors should: • Assure themselves that they have the information required to take action; • Devote sufficient time to reviewing such information; and • Obtain, if useful, the advice of experts • Directors may rely on information, opinions, reports or statements presented by any other person as to matters reasonably believed to be within such other person’s professional competence when that person has been selected with reasonable care by or on behalf of the corporation • Non-Delegation: The duty of care cannot be delegated to other decision-makers • Recordkeeping: The board should establish an adequate record of the entire decision-making process

  14. Duty of Loyalty • The duty to act in the best interest of the corporation & its stockholders by not putting any personal interest ahead of the interests of the corporation or its stockholders. This duty is implicated when: • Directors stand on both sides of a transaction or otherwise stand to receive a benefit not shared with the stockholders (an “interested” director); or • Directors are beholden to a party with an interest in the transaction (a “non-independent” director) • Directors can have interests that differ from the stockholders if they currently have or stand to receive: • Rollover of equity or options; • Compensation or benefits arrangements post-transaction; • Parachutes or other change-in-control payouts; or • Indemnification, advancement, or insurance • To resolve such conflicts, utilize a combination of: • Full disclosure of conflicts to board and stockholders; • Procedural safeguards throughout the transaction process; and • Special transaction committees

  15. Arguments for imposing fiduciary duties on developers of blockchain systems • Developers/node operators make decisions that impact other users of the system • Protect consumers who rely and who otherwise lack recourse • Mitigate increased (systemic?) risk profile • Lead to better product • Would spur others to mitigate risk • insurance

  16. Arguments against imposing fiduciary duties • Inhibit innovation • Disincentivze coders • Increase development costs • Contract rights • “Code is speech” • More “Satoshis”? • More Vinniks?

  17. Are crypto systems different than other software systems? • Crypto being offered as a replacement for conventional FMI • Property Records • Medical records • Identity • Securities trading & settlement • Already subject to considerable regulation: • PII/PHI • Data breach reporting • Insurance • Audits • Taxation

  18. Principles for Financial Market Infrastructure • Principle 2: Governance: An FMI should have governance arrangements that are clear and transparent, promote the safety and efficiency of the FMI, and support the stability of the broader financial system, other relevant public interest considerations, and the objectives of relevant stakeholders. • Principle 3: Framework for the comprehensive management of risks: An FMI should have a sound risk-management framework for comprehensively managing legal, credit, liquidity, operational, and other risks.

  19. Principles for Financial Market Infrastructure • Principle 17: Operational risk: An FMI should identify the plausible sources of operational risk, both internal and external, and mitigate their impact through the use of appropriate systems, policies, procedures, and controls. Systems should be designed to have a high degree of security and operational reliability and should have adequate, scalable capacity. Business continuity management should aim for timely recovery of operations and fulfillment of the FMI’s obligations, including in the event of a wide-scale or major disruption (PFMI 2012, pp. 1-3). • How does this compare to common practices in public blockchains?

  20. Public Blockchains- a different ethos • “Censorship resistance” is paramount • Little concern for cybersecurity, legal, technical, regulatory risk • Incorporates known often undisclosed technical risks • Little dispute resolution transparency • Few or no documented procedures, policies, practices • Do the benefits of public blockchain systems justify the acceptance of higher levels of operational risk?

  21. Blockchains are just the beginning • Secondary systems built around blockchains compound risk • Wallets: Parity hack • Exchanges: Mt. Gox • Intermediary assets: Tether • Institutionalization of crypto assets

  22. Crypto system governance : BTC • Bitcoin- Anarchy or “rough consensus” • Proposals, discussion, consensus, implementation, via changing group of devs • Subgroup of “core devs” with “commit access” • May be difficult to react quickly and make decisions

  23. Crypto system governance : BTC • Bitcoin- Anarchy or “rough consensus” • Unclear checks and balances • May lack transparency • Unclear if “anyone” will take responsibility. • Core devs- “Cult of personality” • Change over time • Historically core devs have been kicked out by others due to political differences • Are they owed due process? • Should system users be involved in dev selection process? • Should they be paid? • Blockstream pays certain core developers • What about conflicts?

  24. Crypto system governance : ETH • Crowdfunded development & advocacy via “Foundation” • “Cult of Personality” around VitalikButerin • Previously touted “unstoppable applications”

  25. Crypto system governance: ETH • “Unstoppable” applications? • Who “really” decided the response to TheDao attack? • Foundation? • Poll of node operators? • Vitalik? • Public opinion? • Governmental Pressure? • Led to ETH/ETC fork & community split • Should subsequent emergencies be handled the same way? • Why or why not? • Who should decide?

  26. Crypto system governance : EOS • Designed by Dan Larimer

  27. Crypto system governance: EOS Governance is the process by which people in a community: 1. Reach consensus on subjective matters of collective action that cannot be captured entirely by software algorithms; 2. Carry out the decisions they reach; and 3. Alter the governance rules themselves via Constitutional amendments. • Governing body that rules on disputes called EOSIO Core Arbitration Forum • Block producers (group of 21 elected actors who add blocks via proof of stake consensus) execute on ECAF’s rulings • At launch, a constitution adopted

  28. Crypto system governance: EOS • Accounts stolen: 7 individuals without access to their EOS on the mainnet. • Top 21 block producers at the time unanimously voted to freeze the accounts the affected accounts, without an official order from ECAF. • After the freeze of the accounts the block producers filed a dispute against themselves, in order to have their actions reviewed by ECAF. • The actions were ratified by an (emergency) ECAF arbitrator.

  29. Crypto system governance: EOS

  30. Crypto system governance: EOS • Previously allowed for anyone to update their constitution via google doc: • https://docs.google.com/document/d/1JPR-gRb2LOijCyU1sV5aNHJq2EifVLIH2pSwYpnp2Jw/edit

  31. Crypto system governance: EOS • Block producers then stopped complying with the block producer agreement. • Block producers remained in place, supported by whales. • Bribery/vote buying scandal • Continuing political issues: • Insufficient user voting to ratify a new constitution; • Disagreement between DPOS & Decentralization • Overwhelmed ECAF arbitrator • BP’s unilaterally implemented change from interim constitution to user agreement https://cryptoslate.com/block-producers-change-eos-constitution-following-voting-gridlock/

  32. Current Governance Approaches: Decred • Hybrid POS/POW Bitcoin with extrinsic voting governance • Holders can stake DCR in a smart contract in exchange for “tickets” • Tickets are randomly selected to vote on governance matters. • On-chain voting to: • Approve or reject a proposed change to the consensus rules of the protocol. A proposed change must be approved by 75% of non-abstaining tickets to take effect. • Approve the work of PoW Miners. 3/5 must ok block, may reject block in case of “undesirable” behavior by miners. • Politeia off chain proposal voting, goes to the technical direction of the project, spending the DCR project subsidy fund (10% of block rewards) or amending Decred Constitution. • Decred’s development entity is an incorporated Nevis LLC

  33. Current Governance Approaches: are they all wrong? • All crypto systems are based in part on game theory & based on assumptions of user self-interested behavior • Decentralization in POW needed to avoid 51% attack • Assumed that good actors would leave the chain, because records not reliable, double spends are disfavored • Are people always rational? Are markets always rational? https://www.crypto51.app/ + Bitmex options = Profit?

  34. CFTC suggests developer liability • Commissioner Quintenz, addressing developer liability for code released, 10/17/18:

  35. Quintenz suggests developer liability • Commissioner Quintenz:

  36. Legal theory of liability • Developer who reasonably foresees that software provided to the market would be used to violate CFTC law would be liable for aiding and abetting. • Elements of Aiding & Abetting violation of CFTC law: https://www.cftc.gov/sites/default/files/2018-07/enflansingtradegroupllcorder071218.pdf • the Commodity Exchange Act (CEA) was violated; • the defendant knew of the wrongdoing underlying the violation; and • the defendant intentionally assisted the principal wrongdoers. • 3rd Circuit Test: Nicholas v. Saul Stone & Co., 224 F.3d 179, 189 (3rd Cir. 2000); • “knowledge of the principal’s intent to commit a violation of the Act;” • “intent to further that violation;” and • “some act in furtherance of the principal’s objective.”

  37. Legal theory of liability • Does “reasonably foresee” make sense here? • How durable is this test in the context of released code? • Example: Precursor chemicals • Blurry lines around “reasonably foresee” • “Unintended” aiding and abetting • Unusual conflation of statutory law and tort theories

  38. But, my open source license?! • License agreement is a contract- who is bound? • Code developer & user of code • Does not bind regulator • Cannot disclaim compliance with regulatory regime intended to protect others • Ex.: Parent/child & driver’s license • Ex.: Knocking down a building • Securities law • Commodities law

  39. But, code is speech! • Speech/not speech is not the right question • Protection of speech is not unlimited • FCC v. Pacifica Foundation, 438 U.S. 726 (1978): indecent speech may be limited • “Falsely shouting fire in a theatre and causing a panic”- Schenck v. United States, 249 U.S. 47 (1919), J. Holmes • Time place and manner restrictions on speech must be (a) content neutral, (b) narrowly tailored to serve a significant governmental interest and (c) must leave open ample alternative channels for communicating the speaker’s message. Ward v. Rock Against Racism  491 U.S. 781 (1989).

  40. But, code is speech!

  41. But, code is speech!

  42. Where does this leave us? • Crypto is still an experiment that on many levels still requires humans. • FMI is usually mass production software, subject to considerable QA. • Blockchains aren’t built like robust commercial products. • Hard for consumers to vet code and understand software. • Even when given information, ignored. • Logical that companies seek shelter with IBM, Deloitte, PWC. • Shared responsibility of those who implement software and those who use software.

More Related