Operational Risk Research Papers - Academia.edu (original) (raw)

Every reader of this Handbook will be well aware that blockchain technology, also called 'distributed ledger technology' or 'DLT', is all the rage in financial circles at the moment. One cannot escape white papers by various banks and consulting firms, speeches by central bankers, and a deluge of articles, books, conferences, summits, and workshops proclaiming the imminent transformation of the financial system by this revolutionary technology. The Gardner Hype Cycle put blockchain technology at virtually the top of its hype cycle curve in the summer of 2016, indicating that the zeitgeist around blockchain technology is soon to fall into the " trough of disillusionment " as sky-high expectations collide with harsh realities (Burton, B. and D. Willis 2016). This chapter delves into some of those harsh realities, as it focuses on the risks created by the use of what I call 'grassroots' open source software 1 methods in the operation of public blockchains, and the resulting fragility of any systems that rely on public blockchains as underlying technological infrastructure. Public blockchains, otherwise referred to as 'open' or 'permissionless' blockchains, allow anyone to become part of the computer network that maintains the blockchain; to join, one simply downloads and begins to run the applicable software. Private blockchains, otherwise referred to as 'closed' or 'permissioned' blockchains, allow only those who have received 'permission' to join the computer network that maintains the blockchain, thus limiting the transaction processing network to those who are known and trusted. Public and private blockchains are diametrically opposed to one another, and the seemingly simple decision about access to the network of transaction processors fundamentally changes the risk profile (as well as the capabilities and emergent properties) of a blockchain. This chapter limits its analysis to public blockchains, and explores how the use of three common practices from the grassroots open source software world gives rise to operational risks for these blockchains. These practices are: (1) the use of the informal, semi-decentralized grassroots open source software development process to maintain the blockchain software; (2) the use of the funding model (or lack thereof) for grassroots open source software development; and (3) the practice of forking software code that is an inherent feature of open source software. 1 In this chapter, I distinguish between " grassroots " open source software (" community-developed, " Nyman 2015, p. 24) and " corporate " open source software. The distinction between the two is generally that " grassroots " open source software emerges organically from and is maintained by a community of software developers (sometimes with the assistance of a purpose-built non-profit foundation), while a " corporate " open source software project is created, owned, and controlled by a formal business entity, with some sort of participation from the larger developer community (Nyman 2015).