Open Source Operational Risk

1. Open Source Operational Risk Angela Walch Associate Professor St. Mary’s University School of Law Research Fellow, UCL Centre for Blockchain Technologies Should Public Blockchains Serve as Financial Market Infrastructures? Blockchain Protocol Analysis & Security Engineering 2017 Stanford Cyber Initiative January 26, 2017

2. Main Questions • How do common practices from “grassroots” open source software generate operational risks for public blockchains? • Are these risks ok for financial market infrastructures? Blockchain Protocol Analysis & Security Engineering 2017

3. How We’ll Proceed • Background on critical nature of financial market infrastructures and practices global regulators see as important in ensuring their uninterrupted operation. • Discussion of how common practices from grassroots open source software generate operational risks for public blockchains. Blockchain Protocol Analysis & Security Engineering 2017

4. The “Beating Heart” of Finance Blockchain Technology Blockchain Protocol Analysis & Security Engineering 2017

5. Operational Risk The risk that deficiencies in information systems or internal processes, human errors, management failures, or disruptions from external events will result in the reduction, deterioration, or break-down of services provided by the [financial market infrastructure]…includ[ing] physical threats, such as natural disasters and terrorist attacks, and information security threats, such as cyberattacks. Further, deficiencies in information systems or internal processes include errors or delays in processing, system outages, insufficient capacity, fraud, data loss, and leakage. (Federal Reserve) Blockchain Protocol Analysis & Security Engineering 2017

6. Principles for Financial Market Infrastructures • 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). Blockchain Protocol Analysis & Security Engineering 2017

7. 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. Blockchain Protocol Analysis & Security Engineering 2017

8. 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. Blockchain Protocol Analysis & Security Engineering 2017

9. Grassroots Open Source Software • How software development is governed. • How software development is funded. • The forking feature. Blockchain Protocol Analysis & Security Engineering 2017

10. Decentralized, Undefined Governance • No official responsibility/accountability to keep software operational. • No one is the official “decider.” • Unacknowledged Centralization of Power • Unaccountable • Unchecked • Lead to  Paralysis/Delay in fixing code. Blockchain Protocol Analysis & Security Engineering 2017

11. Problematic Funding Model • Grassroots OSS development generally uncompensated. • Inadequate care of critical OSS projects? • Heartbleed / Core Infrastructure Initiative / Mozilla’s SOS • Bitcoin had luxury of low-stakes youth. • No one is low-stakes now. • Experiments in funding: • Pre-sales, Tokens, ICOs. • Private Companies / Sponsorships • Conflicts of Interest? How stable is funding source long-term? Are consumers protected? Blockchain Protocol Analysis & Security Engineering 2017

12. Forks • Possible Outcomes: • Peaceful coexistence of old and new • Old dies • New dies • Contentious coexistence of old and new • Consequences significant for Public Blockchains. • Embed and transfer actual value • Serve as authoritative record of events Blockchain Protocol Analysis & Security Engineering 2017

13. Real World Examples • March 2013 Hard Fork • Different versions incompatible. • 2 ledgers. • Human Coordination to fix (requiring ALTRUISM) • Bitcoin Block Size Debate • Political Question  Not just technical. • Paralysis because consequences so extreme. • Ethereum’s July 2016 Hard Fork • Ethereum & Ethereum Classic Blockchain Protocol Analysis & Security Engineering 2017

14. Lessons Learned • New software releasesfractured networks. • Fixing forks may need human coordination. • Core devs wield a lot of power/influence. • Risk of forks  Paralysis. • Upper-level apps can impact underlying blockchain. • Neither humans nor code are perfect. • Competing Blockchains are possible outcome of fork. • Which is legitimate? • If embed critical records, which is “correct”? Blockchain Protocol Analysis & Security Engineering 2017

15. Chaining People Together • Magnified software risks for structures atop them. • Community commits to staying together for system to have value – 1 authoritative record. • Each potential hard fork like binding secession referendum. • If don’t go w/ majority  you’ve seceded. • Build your own! Blockchain Protocol Analysis & Security Engineering 2017

16. Reflections • Undefined governance, problematic funding, and forking chance create operational risks for public blockchains. • As practices are tweaked, risks change. • Very different from how we operate current FMI’s. • Clear governance. • Comprehensive risk management. • Identifying and mitigating operational risks. • Broader Implications -- think about use of grassroots OSS practices in other critical systems? Blockchain Protocol Analysis & Security Engineering 2017