A Tour of Emerging Cryptographic Technologies | GovAI

A Tour of Emerging
Cryptographic
Technologies
What They Are and
How They Could Matter
May 2021
Ben Garfinkel
Centre for the Governance of AI,
Future of Humanity Institute,
University of Oxford

Abstract
Historically, progress in the /fi.ligaeld of cryptography has been enormously consequential.
Over the past century, for instance, cryptographic discoveries have played a key role in
a world war and made it possible to use the internet for business and private communi-
cation. In the interest of exploring the impact the /fi.ligaeld may have in the future, I con-
sider a suite of more recent developments. My primary focus is on blockchain-based tech-
nologies (such as cryptocurrencies) and on techniques for computing on con/fi.ligadential data
(such as secure multiparty computation). I provide an introduction to these technolo-
gies that assumes no mathematical background or previous knowledge of cryptography.
Then, I consider several speculative predictions that some researchers and engineers have
made about the technologies’ long-term political signi/fi.ligacance. This includes predictions
that more “privacy-preserving” forms of surveillance will become possible, that the roles
of centralized institutions ranging from banks to voting authorities will shrink, and that
new transnational institutions known as “decentralized autonomous organizations” will
emerge. Finally, I close by discussing some challenges that are likely to limit the signi/fi.ligacance
of emerging cryptographic technologies. On the basis of these challenges, it is premature
to predict that any of them will approach the transformativeness of previous technologies.
However, this remains a rapidly developing area well worth following.
Report background
This report was written as a follow-up to a /two.lf/zero.lf/one.lf/six.lf workshop at the Future of Humanity In-
stitute, exploring the implications of blockchain technology. The workshop participants
were Stuart Armstrong, Shahar Avin, Nick Bostrom, Miles Brundage, Vitalik Buterin, Je/f\_f.liga
Coleman, Owen Cotton-Barratt, Wei Dai, Owain Evans, Virgil Gri/f\_f\_i.ligath, Georgios Pil-
iouras, Anders Sandberg, and Vlad Zam/fi.ligar. I later expanded the report by drawing on
sources ranging from academic journal articles to blog posts to technical whitepapers to
informal conversations with researchers and engineers in this space. The goal was to write
something that would allow complete non-experts (like myself when I began the project)
to quickly understand what these new technologies are and why so many people are excited
or worried about them.
Most of this report’s text dates back to /two.lf/zero.lf/one.lf/seven.lf. Fortunately, because the report’s focus is on
fundamental principles and limitations, I have only felt the need to make modest revisions
in the intervening years. At least as of Spring /two.lf/zero.lf/two.lf/one.lf, I believe it can still be read as an
accurate description of the state of /fi.ligaeld./one.lf
/one.lfThank you to Je/f\_f.liga Coleman, Rhys Lindmark, Jaan Tallinn, Morten Dahl, Andrew Trask, Allan Dafoe, Jan
Leike, Anish Mohammed, Luke Muehlhauser, Carrick Flynn, Pablo Sta/f\_f.ligaorini, Nick Brown, and Oge Nnadi for
detailed comments on previous drafts of this report. Thank you as well to Anne le Roux, Laura Pomarius, and
Justis Mills for help with the preparation of the report.
/one.lf
Contents
/one.lf Introduction /four.lf
/two.lf Cryptographic technologies: de/fi.liganitions, explanations, and examples /six.lf
/two.lf./one.lf Public-key encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /seven.lf
/two.lf./two.lf Digital signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /one.lf/one.lf
/two.lf./three.lf Cryptographic hash functions . . . . . . . . . . . . . . . . . . . . . . . . /one.lf/two.lf
/two.lf./four.lf Trusted timestamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /one.lf/two.lf
/two.lf./five.lf Tamper-evident logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /one.lf/three.lf
/two.lf./six.lf Blockchains and distributed computing . . . . . . . . . . . . . . . . . . . /one.lf/six.lf
/two.lf./six.lf./one.lf Background: Concepts in distributed computing . . . . . . . . . /one.lf/six.lf
/two.lf./six.lf./two.lf Blockchains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /one.lf/eight.lf
/two.lf./six.lf./three.lf Consensus protocols . . . . . . . . . . . . . . . . . . . . . . . . . /two.lf/two.lf
/two.lf./seven.lf Cryptocurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /two.lf/five.lf
/two.lf./eight.lf Zero-knowledge proofs . . . . . . . . . . . . . . . . . . . . . . . . . . . . /two.lf/nine.lf
/two.lf./nine.lf Smart property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /three.lf/two.lf
/two.lf./one.lf/zero.lf Smart contracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /three.lf/four.lf
/two.lf./one.lf/one.lf Homomorphic encryption . . . . . . . . . . . . . . . . . . . . . . . . . . /three.lf/six.lf
/two.lf./one.lf/two.lf Functional encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /three.lf/seven.lf
/two.lf./one.lf/three.lf Secure multiparty computation and secret sharing . . . . . . . . . . . . . /three.lf/eight.lf
/three.lf Speculative consequences /four.lf/two.lf
/three.lf./one.lf Consequences from technologies other than blockchain . . . . . . . . . . /four.lf/two.lf
/three.lf./one.lf./one.lf Information channels used to conduct surveillance could “go dark” /four.lf/two.lf
/three.lf./one.lf./two.lf Privacy-preserving surveillance could become feasible . . . . . . . /four.lf/four.lf
/three.lf./one.lf./three.lf Non-intrusive agreement veri/fi.ligacation could become feasible . . . /four.lf/eight.lf
/three.lf./one.lf./four.lf It could become easier to combat forgery . . . . . . . . . . . . . . /four.lf/nine.lf
/three.lf./two.lf Consequences from blockchain-based technologies . . . . . . . . . . . . . /five.lf/zero.lf
/three.lf./two.lf./one.lf Background: Concepts in institutional economics . . . . . . . . . /five.lf/zero.lf
/three.lf./two.lf./two.lf The roles of banks, technology companies, voting authorities, and
other traditional institutions could shrink . . . . . . . . . . . . . /five.lf/two.lf
/three.lf./two.lf./three.lf It could become possible to solve collection action problems that
existing institutions cannot . . . . . . . . . . . . . . . . . . . . . /five.lf/three.lf
/three.lf./two.lf./four.lf A new variety of institutions, known as “decentralized autonomous
organizations,” could emerge . . . . . . . . . . . . . . . . . . . . /five.lf/eight.lf
/four.lf Limitations and skeptical views /six.lf/two.lf
/four.lf./one.lf Limitations of privacy-preserving technologies . . . . . . . . . . . . . . . /six.lf/two.lf
/four.lf./one.lf./one.lf The ine/f\_f\_i.ligaciency of computing on con/fi.ligadential data . . . . . . . . /six.lf/two.lf
/four.lf./two.lf Limitations of blockchain-based technologies . . . . . . . . . . . . . . . . /six.lf/three.lf
/four.lf./two.lf./one.lf The di/f\_f\_i.ligaculty of “scaling” permissionless blockchains . . . . . . . /six.lf/three.lf
/four.lf./two.lf./two.lf The threat of restrictive regulations . . . . . . . . . . . . . . . . . /six.lf/five.lf
/four.lf./two.lf./three.lf The potential insecurity of permissionless blockchains . . . . . . /six.lf/six.lf
/four.lf./two.lf./four.lf The inadequacies of smart contracts . . . . . . . . . . . . . . . . /six.lf/eight.lf
/four.lf./two.lf./five.lf The possibility that existing institutions are “good enough” . . . . /seven.lf/one.lf
/two.lf
A Relevance of progress in arti/fi.ligacial intelligence /nine.lf/zero.lf
A./one.lf AI systems may enable more e/f\_f.ligaective surveillance . . . . . . . . . . . . . /nine.lf/zero.lf
A./two.lf AI systems may help to make privacy-preserving surveillance feasible . . . /nine.lf/zero.lf
A./three.lf AI systems may increase the need for anti-forgery schemes . . . . . . . . /nine.lf/one.lf
A./four.lf Methods of computing on con/fi.ligadential data could reduce barriers to de-
veloping certain AI systems . . . . . . . . . . . . . . . . . . . . . . . . . . /nine.lf/one.lf
A./five.lf The problems of safe AI design and safe smart contract design may be
connected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /nine.lf/one.lf
A./six.lf New coordination and veri/fi.ligacation mechanisms may be useful for govern-
ing AI systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /nine.lf/two.lf
A./seven.lf Fully homomorphic encryption may have applications in AI safety and
security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . /nine.lf/two.lf
/three.lf
/one.lf Introduction
The past century saw the emergence of a number of transformative technologies, ranging
from nuclear weapons to computers.
For the sake of anticipating future challenges and opportunities, it is worth considering
which areas of technology, if any, could play similarly consequential roles this century. One
area that has recently provoked a great deal of excitement is cryptography , or the study of
techniques for encoding, protecting, and authenticating data.
Arguably, progress in cryptography (and its complementary /fi.ligaeld, cryptanalysis , which fo-
cuses on decoding) should already be included on any list of the most consequential devel-
opments of the past century [/one.lf/three.lf]. The most famous case of cryptography and cryptanalysis
in the /two.lf/zero.lfth century may be Germany’s use of then-advanced encryption during the Second
World War and Britain’s corresponding cryptanalysis e/f\_f.ligaort, which at least one historian
has estimated sped up Allied victory by more than a year [/nine.lf/four.lf]. More recently, crypto-
graphic technologies developed in the last /fi.ligafty years have allowed the internet (and other
long-distance communication channels) to be used for otherwise impractical purposes,
such as making /fi.liganancial transactions and sending private messages. In addition, the suc-
cessful use of encryption has posed a continuing challenge to government surveillance and
intelligence programs.
Over the past decade, a number of new cryptographic technologies have begun to emerge
(see Tables /one.lf and /two.lf). These technologies include blockchains, which have enabled the cre-
ation of highly reliable records and computer applications that no single party controls;
cryptocurrencies, such as bitcoin, which have accrued hundreds of billions of dollars of
value and allow users to make digital transactions without relying on traditional /fi.liganancial
institutions or traditional /fi.ligaat currencies; smart contracts, which allow users to enter into
agreements that are enforced largely by algorithms; and fully homomorphic encryption,
which allows users to process data without having access to it in unencrypted form./two.lfSome
existing technologies, such as secure multiparty computation, have also become much more
practical to implement or found novel applications.
It remains to be seen whether these recent developments in cryptography will be as sig-
ni/fi.ligacant as those that came before. However, a number of fairly radical claims have been
made about their importance. I list just a few examples: The United Kingdom’s Gov-
ernment O/f\_f\_i.ligace for Science has described blockchains as the /fi.ligarst signi/fi.ligacant innovation
in record-keeping since ancient times [/one.lf/seven.lf/nine.lf]. Ralph Merkle, one of the founding /fi.ligagures
of modern cryptography, has written a paper arguing that blockchains will enable novel
forms of democracy [/one.lf/one.lf/three.lf]. Jaan Tallinn, co-founder of Skype and the Future of Life Insti-
tute, has advocated for the use of smart contract technology to solve global collective ac-
/two.lfSome of these technologies, particularly cryptocurrencies and smart contracts, di/f\_f.ligaer from more traditional
cryptographic technologies in a pair of important ways. First, they depend in part on systems of economic in-
centives to function, and second, their applications primarily concern the transfer of property. For these reasons,
it may be more appropriate to refer to them as “cryptoeconomic” technologies, as some engineers working to
develop them currently do [/one.lf/five.lf/four.lf]. However, since no standard terminology has yet been adopted, I will continue
to use the term “cryptography” as a catch-all.
/four.lf
tion problems [/three.lf/five.lf]. Elsewhere, researchers have argued that cryptocurrencies could make it
much more di/f\_f\_i.ligacult for governments to in/fl.ligauence or trace private transactions, while oth-
ers have written that homomorphic encryption could enable novel forms of surveillance
that require less infringement of individuals’ privacy [/eight.lf/three.lf, /one.lf/six.lf/six.lf].
Unfortunately, discussions of such claims have often played out in scattered blog posts
and papers that are di/f\_f\_i.ligacult for a non-specialist reader to /fi.ligand or understand. This report
is intended to be a contribution to the project of gathering and clarifying these discus-
sions.
In particular, this report is divided into three sections: First, I introduce some recent de-
velopments in cryptography, aiming to include close to the minimum level of detail needed
to discuss the relevant technologies clearly. Second, I describe several potential long-term,
politically signi/fi.ligacant consequences. Finally, I explore some of the technical limitations
and political constraints that could prevent these consequences from arising.
In addition, an appendix discusses the relationship between the future of cryptography
and the future of arti/fi.ligacial intelligence.
For readers not already familiar with cryptography, the /fi.ligarst section is best read in order.
However, later subsections are not so dependent on one another.
/five.lf
/two.lf Cryptographic technologies: de/fi.liganitions, explanations, and
examples
The set of cryptographic technologies that we will be considering is highly diverse. Of
interest in this report will be:
•Public-key cryptography
•Digital signatures
•Cryptographic hash functions
•Trusted timestamping
•Tamper-evident logs
•Blockchains
•Cryptocurrencies
•Zero-knowledge proofs
•Smart property
•Smart contracts
•Homomorphic encryption
•Functional encryption
•Secure multiparty computation and secret sharing
Some of these technologies are new, having been developed primarily in just the last /fi.ligafteen
years. Some are older, but either serve as core components of these newer technologies or
continue to /fi.ligand additional applications of their own. In this section, I aim to provide
descriptions of each technology that are su/f\_f\_i.ligacient to enable informed discussions of their
potential applications and limitations.
For an overview, Tables /one.lf and /two.lf provide a highly abridged summary. In addition, for a
deeper look, I will now also recommend some sources for further reading.
Readers interested in more thorough or technical descriptions of well-established tech-
nologies, like public-key encryption, digital signatures, and cryptographic hash functions,
can /fi.ligand them in any of a number of widely used introductory textbooks, such as Introduc-
tion to Modern Cryptography by Jonathan Katz and Yehuda Lindell [/nine.lf/nine.lf].
Readers interested in blockchains, cryptocurrencies, smart property, and smart contracts
can /fi.ligand discussions of them in the textbook Bitcoin and Cryptocurrency Technologies , by
Narayanan et al. [/one.lf/one.lf/nine.lf]. Vitalik Buterin’s whitepaper for the Ethereum blockchain and
Ethan Buchman’s thesis outlining the Tendermint blockchain also continue to serve as
good introductions to blockchain technology itself [/four.lf/one.lf, /three.lf/four.lf]. Many of Vitalik Buterin’s blog
posts also provide unusually clearheaded descriptions of di/f\_f.ligaerent aspects of blockchain
ecosystem [/three.lf/eight.lf, /three.lf/nine.lf].
Zero-knowledge proofs and secure multiparty computation receive coverage in many in-
termediate cryptography textbooks. There are a handful of book-length treatments. For an
introduction to zero-knowledge proofs that focuses on recent developments, I recommend
the “Explaining SNARKs” series on the Zcash blog [/one.lf/eight.lf/six.lf]. For an accessible introduction to
/six.lf
secure multiparty computation, I recommend the paper “Secure Multiparty Computation
for Privacy-Preserving Data Mining” by Lindell and Pinkas [/one.lf/zero.lf/eight.lf]. In addition, Vaikun-
tanathan’s “Computing Blindfolded: New Developments in Fully Homomorphic Encryp-
tion” [/one.lf/seven.lf/one.lf] and Boneh et al.’s “Functional Encryption: De/fi.liganitions and Challenges” [/two.lf/seven.lf] are
reasonable introductions to homomorphic encryption and functional encryption respec-
tively.
Finally, it is important to note that the list of technologies I have chosen to investigate
is not exhaustive. Among areas I have excluded, the most important may be the sub/fi.ligaeld
ofquantum cryptography , which applies quantum phenomena to cryptographic tasks. This
exclusion is primarily a matter of limited space, although it is also worth noting that many
of the most interesting technologies associated with quantum cryptography (such as quan-
tum money andquantum copy-protection ) stand out as particularly far from seeing practical
applications [/one.lf]. Other potentially signi/fi.ligacant technologies, not discussed in this report, in-
clude program obfuscation andveriﬁable computing. Program obfuscation allows users to share
computer programs with others while leaving their inner workings opaque, and veri/fi.ligaable
computing allows users to outsource computations to others and receive short proofs that
the computations have been executed as promised [/one.lf/three.lf/nine.lf, /one.lf/seven.lf/eight.lf]. Both of these technologies
are also associated with a number of breakthroughs in the past decade.
/two.lf./one.lf Public-key encryption
Public-key encryption is a technology that allows users to communicate through code with-
out sharing secret information ahead of time [/five.lf/seven.lf, /nine.lf/nine.lf].
Say that one party, Alice, wants to send a private message to some other party, Bob, using a
channel that may have eavesdroppers. For example, Alice might want to share a secret with
Bob over e-mail without anyone else—such as a government intelligence agency—being
able to learn the secret too. The way to do this is to encrypt the message, meaning to
encode it in a way that no one else can understand.
The oldest class of encryption schemes, known as symmetric key schemes, has been used for
thousands of years. These schemes rely on a single shared piece of information, known as a
secret key , and a mutually understood rule for translating unencrypted messages (or plain-
text) and encrypted messages (or ciphertext ) into one another using that key. For example,
in the simple “Caesar cipher” the key was a short number, X, and the rule for translat-
ing plaintext to ciphertext was to move each individual letter forward by Xplaces in the
alphabet./three.lf
The trouble with symmetric key schemes is that, to be used, both parties must somehow
settle on a secret key without any third parties learning it too. However, the di/f\_f\_i.ligaculty of
communicating secret information such as this is exactly the di/f\_f\_i.ligaculty that encryption is
meant to solve in the /fi.ligarst place. Private key cryptography schemes therefore su/f\_f.ligaer from
a “chicken and egg” problem. The problem is further exacerbated by the fact that secret
keys cannot be reused without a very signi/fi.ligacant loss of security.
/three.lfAs an example, the key “/one.lf” would turn the message “HELLO” into “IFMMP.”
/seven.lf
Technology Origin Functional description
Public-key encryption /one.lf/nine.lf/seven.lf/three.lf Allows users to communicate through code without
sharing secret information ahead of time
Digital signatures /one.lf/nine.lf/seven.lf/nine.lf Allows users to identify messages’ senders
Cryptographic hash functions /one.lf/nine.lf/seven.lf/nine.lf Allow users to associate data with unique “digital
/fi.ligangerprints”
Trusted timestamping /one.lf/nine.lf/nine.lf/one.lf Allows users to timestamp pieces of data
Tamper-evident logs /one.lf/nine.lf/seven.lf/nine.lf (ambiguous) Contain chronological records that cannot be
inconspicuously edited
Replicated state machines /one.lf/nine.lf/eight.lf/four.lf Replicate the provision of a service across multiple
computers
Blockchains /two.lf/zero.lf/zero.lf/eight.lf Replicated state machines that maintain
tamper-evident logs
Permissionless blockchains /two.lf/zero.lf/zero.lf/eight.lf Blockchains that allow any computer to participate in
service provision
Decentralized applications /one.lf/nine.lf/eight.lf/zero.lf (ambiguous) Applications associated with an open-ended set of
service providers (as in a permissionless blockchain)
Consortium blockchains /two.lf/zero.lf/one.lf/two.lf (ambiguous) Blockchains that allow computers owned by multiple
parties (but not any computer) to participate in service
provision
Consortium-backed applications Ambiguous Applications associated with multiple privileged
service providers (as in a consortium blockchain)
Cryptocurrencies /two.lf/zero.lf/zero.lf/eight.lf Digital currencies whose ownership is managed through
a decentralized or consortium-backed application; are
also essential to the operation of permissionless
blockchains
Table /one.lf: Summary of cryptographic technologies, part /one.lf
/eight.lf
Technology Origin Functional description
Zero-knowledge proofs /one.lf/nine.lf/eight.lf/five.lf Allow users to prove mathematical statements to others
without conveying additional information
zk-SNARKs /two.lf/zero.lf/one.lf/zero.lf Allow users to do the above succinctly and without
back-and-forth interactions
Physical zero-knowledge proofs /two.lf/zero.lf/one.lf/two.lf (ambiguous) Allow users to prove statements about physical objects
to others without conveying additional information
Smart property /one.lf/nine.lf/nine.lf/four.lf Devices with electronic components that facilitate that
transfer of their ownership
Smart contracts /one.lf/nine.lf/nine.lf/four.lf Contracts whose execution is automated to a
signi/fi.ligacant extent
Homomorphic encryption /one.lf/nine.lf/seven.lf/three.lf Allows users to perform certain computations on
encrypted data; outputs are also encrypted
Fully homomorphic encryption /two.lf/zero.lf/zero.lf/nine.lf Allows users to perform anycomputations on
encrypted data; outputs are also encrypted
Functional encryption /two.lf/zero.lf/one.lf/zero.lf Allows users to perform certain computations on
encrypted data, such that the outputs are notencrypted
Secure multiparty computation /one.lf/nine.lf/eight.lf/two.lf Allows users to run computations with inputs from
multiple parties, while allowing these parties to keep
their own inputs secret
Secret sharing /one.lf/nine.lf/seven.lf/nine.lf Allows users to split private data into shares, which can
be recombined to retrieve the data
Table /two.lf: Summary of cryptographic technologies, part /two.lf
/nine.lf
Public-key cryptography , /fi.ligarst developed in the /one.lf/nine.lf/seven.lf/zero.lfs, solves this problem. In a public-key
scheme, there is not a single key. Instead, each person in a network has a unique pair of
keys: one known as their private key and one known as their public key . Although technical
details need not concern us, these are the de/fi.liganing traits of a public-key system:
•There is a setup algorithm that each party in the system can use to generate an (almost
certainly) unique key pair.
•Each party in the system can announce their public key without revealing their pri-
vate key. Public keys may also be used as digital pseudonyms.
•There is an encryption algorithm that can take a plaintext message and the recipient’s
public key as inputs and then produce an encoded message as an output. There is also
adecryption algorithm that that can take an encoded message and the recipient’s pri-
vate key and then produce the original message as an output. By applying these two
algorithms in sequence, the sender and recipient can communicate through code./four.lf
•There is no practical algorithm that would allow anyone without the recipient’s
private key to decode the sender’s message.
As stated above, public-key cryptography is not a new technology. After its initial de-
velopment (or, more precisely, rediscovery by academics outside of the classi/fi.ligaed research
community), the possibility of its widespread adoption was for many years considered a
threat by government agencies such as, within the United States, the NSA and the FBI [/one.lf/one.lf].
These agencies argued that, without the ability to read intercepted messages, they would
be much less able to counter criminal activity and other threats to security. They pur-
sued several strategies to either slow the technology’s adoption or outlaw variants that did
not grant the government a “backdoor” to decrypt messages using its own special private
keys.
Ultimately, it became clear by the late /one.lf/nine.lf/nine.lf/zero.lfs that these agencies had lost the /fi.ligaght, and, at
least within the United States and European Union, all forms of public-key cryptography
are now perfectly legal to use [/one.lf/four.lf/zero.lf]. Until recently, though, the vast majority of messaging
services still applied encryption in a way that allowed the service provider, and therefore
government agencies, to access their users’ unencrypted messages. Partially as a reaction
to the /two.lf/zero.lf/one.lf/three.lf Snowden leaks, this state of a/f\_f.ligaairs has begun to change. It has become in-
creasingly common for services to o/f\_f.ligaer end-to-end encryption , which, in practice, refers to
implementations of encrypted messaging that do not grant service providers viewing priv-
ileges [/five.lf/nine.lf]. Over the course of just /two.lf/zero.lf/one.lf/six.lf, the number of end-to-end encryption users across
all services may have increased by over one billion, due largely to WhatsApp’s decision to
begin enabling the feature by default [/one.lf/two.lf]. In addition, a number of groups are working to
develop practical end-to-end messaging services that can also reliably obscure each mes-
sage’s metadata, such as its recipient [/one.lf/seven.lf/two.lf]. If such projects are ultimately successful, then
/four.lfTo express this mathematically, let Encbe the encryption algorithm, Decbe the decryption algorithm, u
be a user’s public key, rbe the same user’s private key, and mbe a message. Then, Enc(m,u) is illegible, and
Dec(Enc(m,u),r) =m. Alternatively, to express this by analogy, we can think of a user’s “public key” as actually
being a particular lock design, which others use to protect the messages sent to them, and the user’s “private key”
as the key that opens the lock.
/one.lf/zero.lf
user privacy may increase even further.
While even the use of perfectly implemented end-to-end encryption does not guarantee
that one’s messages will not be read by anyone other than the intended recipient, it does
decrease the odds of successful eavesdropping./five.lfAgencies in a number of countries now
allege, controversially, that the information channels they rely on are increasingly “going
dark” [/seven.lf/zero.lf].
/two.lf./two.lf Digital signatures
Adigital signature can be used to demonstrate that a given piece of data was sent by the
owner of a particular key pair (see section /two.lf./one.lf) and that it has not been modi/fi.ligaed since its
sending [/one.lf/three.lf/six.lf, /nine.lf/nine.lf].
Digital signatures work in the following way:
•Each party in the system agrees on a signing algorithm and a signature-verifying algo-
rithm .
•The signing algorithm takes a party’s private key and a piece of data and outputs a
code known as a signature .
•The signature-verifying algorithm takes a party’s public key, a piece of data, and a
signature, and outputs “Yes” if and only if the signature was generated from the data
and the corresponding private key./six.lf
The use of digital signatures is currently ubiquitous online and, among many other ap-
plications, enables online commerce. For example, when you shop online, your computer
veri/fi.ligaes that you are in fact connected to Amazon.com (and not a scammer after your credit
card details) by checking a signature it sends against a public key known to be associated
with the website.
In recent years, some countries have also moved toward assigning their citizens public keys
as a form of identi/fi.ligacation, so that individuals can prove their identities, access personally
relevant government records, vote, and even sign legally binding contracts using digital sig-
natures (ordinarily stored on highly protected ID cards) [/one.lf/one.lf/zero.lf]. Estonia is the most notable
case, with its citizens having issued hundreds of millions of signatures since the program’s
inception.
/five.lfA third party might still read the messages if they gain access to the intended recipient’s private key and
intercept the message, if they trick the sender into associating the intended recipient with their own private key,
if they manage to install malware on either the sender’s or the recipient’s device, and so on. In addition, there
remains a risk that the application developer has misrepresented the security or method of encryption used in
their application, as has sometimes occurred.
/six.lfFor example, say that my key pair consists of private key Xand public key Y. If I would like to tell you
“HELLO,” and demonstrate that I am the one telling you this, then I will /fi.ligarst input “HELLO,” and Xinto the
signing algorithm to produce a signature. I will then send you a message consisting of the word “HELLO” followed
by the signature. Finally, if you know my public key, you can apply the verifying algorithm to “HELLO,” Y, and
the signature, and thereby see that I am the one who signed the message.
/one.lf/one.lf
/two.lf./three.lf Cryptographic hash functions
Acryptographic hash function encodes a piece of data as a code of some /fi.ligaxed length, known
as ahash (ordigest ) [/one.lf/one.lf/four.lf, /nine.lf/nine.lf]. The function has the following properties:
•It is easy to check that a given piece of data produces a given hash.
•Pieces of data that are only slightly di/f\_f.ligaerent will produce very di/f\_f.ligaerent hashes.
•It is impractically di/f\_f\_i.ligacult to /fi.ligand a piece of data that will produce a given hash, or
to /fi.ligand two pieces of data that produce identical hashes.
In a sense, hashes act like “digital /fi.ligangerprints” for pieces of data. In the same way that
each human is associated with an almost certainly unique set of /fi.ligangerprints, without these
/fi.ligangerprints providing any other information about the person, each piece of data can be
associated with an almost certainly unique hash, without this hash providing any other
information about the data.
Arguably, hash functions are primarily important as a building block for other crypto-
graphic technologies. We will now discuss a trio of such technologies: trusted timestamping ,
tamper-evident logs , and blockchains.
/two.lf./four.lf Trusted timestamping
One interesting application area for cryptographic hash functions is trusted timestamping ,
or techniques for demonstrating that a given piece of data existed at a given time [/eight.lf/four.lf, /one.lf/seven.lf/zero.lf].
In many cases, the task is signi/fi.ligacantly complicated by the user’s desire to keep the data
private at the time of its timestamping.
For instance, suppose that you have some research result that you are not ready to publish,
but which you would like to be able to claim priority for. One simple solution is to take
the hash of your data and then publish that hash to a newspaper or to a website that can
be trusted to reliably log publication times. Later on, you can publish the actual research
results, and, by comparing its hash against the published hash, people will be able to verify
for themselves that you had the results at the time of the hash’s publication.
As an example of this technique, the political organization WikiLeaks will sometimes post
hashes of sensitive documents that they obtain to Twitter [/one.lf/five.lf/eight.lf]. If the hashes of eventually
released documents do not match—as has happened in at least one case—then it will be
clear that someone has modi/fi.ligaed the documents in the time since WikiLeaks advertised
their existence./seven.lf
/seven.lfHere, Twitter is unintentionally /fi.ligalling the role of Time Stamping Authority (TSA). It is being trusted, in
particular, both to produce authentic timestamps (by publishing accurately dated tweets) and to ensure that
these timestamps will remain available into the inde/fi.liganite future. More sophisticated timestamping protocols
can also remove this second responsibility. For example, rather than storing the hashes it receives from users, the
TSA can send back signed messages that contain both the hash and the time of its receipt. If the user would later
like to convince others that the data existed at this time, then all they need to do is share the signed message
along with the data. Further security can be provided by yet more sophisticated proposals, which replace a TSA
with multiple trusted parties.
/one.lf/two.lf
Other use cases for trusted timestamping include preventing the forgery of documents and
digital media. Often, the fact that a piece of data is known to predate a certain point in
time can provide evidence that it is genuine. Investigators can trust that a timestamped
government document, for example, was not concocted after the fact to cover a corrupt
o/f\_f\_i.ligacial’s tracks. Similarly, if a photograph claims to depict a secret meeting between two
o/f\_f\_i.ligacials on a particular day, it will be much more credible if it is actually timestamped
for that day. As discussed in section /three.lf./one.lf./four.lf, this latter use case may become much more
important as arti/fi.ligacial intelligence becomes increasingly e/f\_f\_i.ligacient and e/f\_f.ligaective at forging
photographs and videos [/four.lf].
As a /fi.liganal technical point, it can sometimes be useful to associate a large collection of data
with a single timestamp. Naively, one simple way to accomplish this task is to apply a hash
function to the full collection together. However, this method has a signi/fi.ligacant downside.
In particular, using this method, it is impossible to demonstrate that a single piece of data
in the collection was used to produce the timestamp without also sharing the rest of the
collection, which may be undesirable from the standpoint of e/f\_f\_i.ligaciency or privacy.
A better method of timestamping a large collection of data at once is to use Merkle trees
(see Figure /one.lf). Merkle trees are produced by hashing each piece of data individually, then
repeatedly hashing pairs of hashes to form a tree structure. The hash that stands at the top
of the resulting tree is known as the Merkle root . The Merkle root, if published, serves just
as well as a “digital /fi.ligangerprint” for the whole collection. If one would like to prove that
an individual piece of data belongs to the timestamped collection, though, then it is only
necessary to share that individual piece and a relatively small portion of the Merkle tree,
rather than it being necessary to share the other pieces of data as well.
Merkle trees were /fi.ligarst proposed in the late /one.lf/nine.lf/seven.lf/zero.lfs, by Ralph Merkle, and have been used
perhaps most often in the context of /fi.ligale hosting and sharing services that wish to assure
users that /fi.ligales have not been altered from their most recent versions.
/two.lf./five.lf Tamper-evident logs
Atamper-evident log is a chronological collection of records that is designed so that any
alterations to records, once they are added, will be easily detectable [/five.lf/five.lf]./eight.lf
Tamper-evident logs are a highly valuable technology, insofar as trustworthy record-keeping
plays a crucial role in political and economic life. One would hope, for example, that one’s
banking records, medical records, tax records, property records, and criminal records con-
tinue to be maintained properly.
In many cases, the records in a log are objects of signi/fi.ligacant interest in their own right. Logs
are often instrumentally useful, though, in allowing users to verify the integrity of more
sophisticated processes or services. For example, a trusted log of deposits, withdrawals,
and transfers can be used to determine the correct balance for a bank account or to restore
it to an earlier value if an error should occur. In general, many computer applications are
/eight.lfThe terminology here is not entirely standard. However, as a technical note, tamper-evident logs can be
classi/fi.ligaed as a particular variety of what are known as authenticated data structures .
/one.lf/three.lf
Figure /one.lf: A Merkle tree. The top hash, or Merkle root , serves as a “digital /fi.ligangerprint” for
the blocks of data at the bottom. Here, proving that Data Block L/one.lf is consistent with the
Merkle root would require sharing just the block itself and the two hashes Hash/zero.lf-/one.lf and
Hash/one.lf. There is no need to share the other data blocks. (Image by David Gäthberg.)
/one.lf/four.lf
Figure /two.lf: A hash-linked log. Any edit to an individual record will produce an inconsistency
with the Merkle root in the block’s header. Furthermore, any edit to a block’s header will
produce an inconsistency with the hash pointer in the following block.
associated with logs, typically referred to as transaction logs , that track how they respond
to user inputs over time.
Granting the parties maintaining such logs the ability to more easily detect attempts to
tamper with them, and to more easily demonstrate to third parties that their logs have not
been tampered with, can be a signi/fi.ligacant boon to security and trust.
One design stands out as particularly e/f\_f.ligaective (see Figure /two.lf). Although the proper termi-
nology is contested, I will refer to it as a hash-linked log . Here, the log is subdivided into
sequential blocks. Every time su/f\_f\_i.ligaciently many new records are collected, they are gath-
ered into a new block and added to the sequence. Each block is divided into two sections,
one that contains records and one that is known as a header . In turn, each header contains
the date, the Merkle root of the records the block contains, and the hash of the previous
header.
Suppose that Alice is maintaining such a log—say, for an online payment service that Bob
uses—and that she publishes the block headers as they are created. By including Merkle
roots in the headers, Alice timestamps each block’s records when she publishes its header.
By including hash pointers in the headers, though, she also goes further and establishes a
canonical sequence of records. It is now impractical, for instance, for Alice to remove a
block from the log without producing an inconsistency with the headers that follow it; she
also cannot simultaneously create two contradictory versions of a block, then inconspicu-
ously swap one out for the other later on./nine.lf
Generally, we can understand hash-linked logs as achieving their security through the use of
linked timestamping , a class of timestamping techniques in which each timestamp references
/nine.lfAs a further bene/fi.ligat of including hash pointers, Bob only really needs to know the most recent header to
detect tampering. Any attempt by Alice to pass o/f\_f.liga an alternative sequence of headers as legitimate would be
foiled by the sequence’s obvious inconsistency with the one that Bob knows.
/one.lf/five.lf
the one before it.
Although the linked timestamping scheme described here dates back to a series of papers
by Haber and Stornetta in the early /one.lf/nine.lf/nine.lf/zero.lfs, a number of governments and companies have
just recently taken an interest in its applications. The aim is both to protect the integrity
of their records and to provide greater assurances to their citizens or clients. The Estonian
government, for instance, began in /two.lf/zero.lf/zero.lf/eight.lf to use a linked timestamping service for logging
alterations to some varieties of government documents. The research company Google
DeepMind also initiated a project, in /two.lf/zero.lf/one.lf/seven.lf, to develop a tamper-evident logging system for
use by the British National Health Service [/nine.lf/one.lf].
/two.lf./six.lf Blockchains and distributed computing
/two.lf./six.lf./one.lf Background: Concepts in distributed computing
In this subsection, we will take a brief break from discussing cryptography directly. In-
stead, we will discuss some concepts in the /fi.ligaeld of distributed computing that will inform
the discussion that follows.
Adistributed application , /fi.ligarst, is an application whose operation requires interaction be-
tween multiple computers. One familiar example of a distributed application is Google
Search. When you use Google, information is constantly being passed back and forth
between your computer and computers managed by the company. Your computer sends
search requests, and it receives search results back in return.
Google Search is also an example of a distributed application that is well-described by the
client-server model . In the client-server model, a set of users, known as clients , request ser-
vices from a service provider, known as a server . Here, your computer would be considered
a client and Google’s would be considered servers.
Other familiar examples of distributed applications that /fi.ligat the client-server model in-
clude e-mail, Facebook, and online banking. As one can see, such applications are ubiqui-
tous.
Servers are not, in general, perfectly reliable. They may experience errors, lose the ability to
receive requests, or otherwise stop functioning properly. One might worry, in particular,
about the integrity of the application a server supports or about its consistent availability
to clients.
One approach to lessening these concerns is known as state machine replication . In state
machine replication, the operations of a single server are reproduced across multiple copies.
These copies, known as nodes , communicate with one another to stay in sync and come to
consensus about the proper responses to requests from clients. Collectively, the nodes can
be conceptualized as constituting a single replicated state machine (RSM ).
The consensus protocols for replicated state machines are designed such that, if some small
portion of nodes are faulty, then the application will continue to respond to clients and
respond appropriately. The most secure of these protocols, which were largely developed
/one.lf/six.lf
in the /eight.lf/zero.lfs and /nine.lf/zero.lfs, can practically guarantee the availability and integrity of an RSM so
long as at least two-thirds of its nodes follow the protocol and remain in contact./one.lf/zero.lf
One feature of such consensus protocols that will be worth noting is that they often depend
on each node storing a log of the requests it has received from clients. Such logs serve
as an important tool for preventing and resolving inconsistencies that arise between the
nodes. So long as they agree on the ordering of this log and follow the same procedure for
responding to sequences of requests, their behavior will be consistent.
The nodes that make up an RSM are typically controlled by a single party, like a technology
company. It is also possible, though, to create RSMs whose nodes are distributed among
multiple parties. I will call such RSMs consortium replicated state machines ./one.lf/one.lfAt least in the-
ory, this strategy can be useful in contexts where any single actor entrusted with providing
a service would su/f\_f.ligaer from a worrisome con/fl.ligaict of interest. The banking industry, for ex-
ample, has recently begun to investigate using RSMs maintained between multiple /fi.ligarms
to run applications that reconcile /fi.liganancial records. Applications supported by consortium
RSMs can be described as consortium-backed applications .
A further step in the direction of decentralization is taken by permissionless replicated state
machines , which place no restrictions at all on which computers can act as nodes. Simply
put, anyone anywhere in the world can participate in maintaining a permissionless RSM.
Applications run using permissionless RSMs can be described as decentralized applications ,
a class of applications in which the set of service providers is open-ended and not centrally
organized./one.lf/two.lf
Intuitively, it is deeply surprising that any permissionless RSM could ever work. Given
that standard RSM consensus protocols fail if even a third of the nodes behave maliciously,
letting in any node that asks to join has the sound of a disastrous idea. Nevertheless, reliable
permissionless RSMs are in fact possible.
Bitcoin, proposed in /two.lf/zero.lf/zero.lf/eight.lf by the pseudonymous engineer Satoshi Nakamoto, provided
the /fi.ligarst-ever example of a permissionless RSM. Designed to implement a decentralized
payment application, allowing users to make and receive payments in a digital currency of
the same name, Bitcoin has proven itself remarkably successful (see section /two.lf./seven.lf). It has de-
veloped millions of users and never itself experienced a signi/fi.ligacant security breach, despite
now tracking the ownership of billions of dollars’ worth of currency. It has inspired both
/one.lf/zero.lfIn cases where the only concern is that some modes might lose contact, then having even half the nodes
function properly is su/f\_f\_i.ligacient.
/one.lf/one.lfThis term, along with the terms “permissionless replicated state machine,” “consortium-backed application,”
and “decentralized application” below, is not standard. However, to my knowledge, there does not yet exist any
strongly established terminology here.
/one.lf/two.lfThere are also some simple applications in this class that do not require service providers to act as an RSM
because it is unnecessary for service providers to synchronize their responses to client requests. For example, in
the decentralized /fi.ligale sharing application BitTorrent, which launched in /two.lf/zero.lf/zero.lf/one.lf, a wide variety of service providers
store pieces of /fi.ligales and individually send these pieces to clients upon request. However, most reasonably com-
plex applications do require the synchronization associated with RSMs. A payment application, for example,
would open itself up to the possibility of users “double-spending” their money if nodes did not agree about what
payments have already been made.
/one.lf/seven.lf
Figure /three.lf: A taxonomy of replicated state machines.
further decentralized payment applications, many of which have been similarly successful,
and a number of decentralized applications, such as those associated with the Ethereum
blockchain (see section /two.lf./one.lf/zero.lf), that aim to provide more sophisticated services.
Bitcoin was created with a seeming lack of awareness of previous work on RSMs./one.lf/three.lfDe-
spite this fact, Bitcoin’s design constitutes an enormous contribution to the /fi.ligaeld. Most
obviously, it provided the /fi.ligarst successful consensus protocol for permissionless RSMs (see
section /two.lf./six.lf./three.lf). However, as the next subsection will discuss, it also played an important
role in integrating the use of RSMs and the use of tamper-evident logs.
/two.lf./six.lf./two.lf Blockchains
The term “blockchain” lacks a standard de/fi.liganition and has been used in several distinct
ways.
By some de/fi.liganitions, blockchains are simply hash-linked logs of the sort depicted in Figure
/two.lf. By other de/fi.liganitions, blockchains appear to be roughly synonymous with replicated state
machines. Perhaps most commonly, the term is also used to refer to a rough constellation
of technologies that de/fi.ligaes easy summary.
In order to draw a clean line between blockchains and technologies that substantially pre-
date the term “blockchain,” however, I will use the following de/fi.liganition:
Ablockchain is a replicated state machine that maintains a hash-linked log.
Blockchains combine the security properties of these two already discussed technologies.
/one.lf/three.lfThe whitepaper proposing Bitcoin does not reference any papers in the literature, and, in general, the term
“replicated state machine” has only recently begun to be used by developers in the associated community.
/one.lf/eight.lf
The use of an RSM helps to ensure the availability of the log and integrity of the process by
which new records are added to it. The use of a hash-chained log then helps to ensure the
integrity of records that have already been added, by ensuring that any attempt to tamper
with them will be easy to detect.
As discussed in sections /two.lf./five.lf, logs are often objects of interest in their own right. However,
in the context of RSMs, logs of clients’ requests are typically a tool for implementing and
auditing more sophisticated services. In Bitcoin, for example, the complete log of transac-
tions in the currency is used to determine the correct amount in a user’s account.
The Bitcoin blockchain, which came online in /two.lf/zero.lf/zero.lf/nine.lf, is perhaps less notable for being the
/fi.ligarst blockchain than it is for being the /fi.ligarst permissionless RSM. The consensus protocol
it implements and the variants it has inspired are general enough—at least in principle—to
allow any application to be run as a decentralized application. The fact these early proto-
cols relied on tamper-evident logs was, in some sense, of secondary interest.
However, since /two.lf/zero.lf/zero.lf/nine.lf, the idea of associating RSMs with hash-linked logs has also received
broader interest. In the past few years, companies like IBM have published designs for
permissioned blockchains that lightly adapt existing RSM algorithms to provide gains in
both integrity and e/f\_f\_i.ligaciency. A number of companies and government bodies who have
not previously used RSMs or tamper-evident logs have begun to explore the possibility of
shifting some of their existing services to blockchains. In addition, perhaps even more ac-
tors have moved to adopt or expand their use of tamper-evident logs in general. A linked
timestamping service provided by the company Guardtime, for example, has begun to be
applied to a large portion of Estonian governmental records. In media accounts and pro-
motional materials, such services are typically described as implementing “blockchains.”
However, in the context of this report’s less expansive terminology, this labeling would be
incorrect.
Starting in approximately /two.lf/zero.lf/one.lf/one.lf, private sector interest in blockchains spilled over into pro-
posals for implementing consortium blockchains. As stated above, consortium blockchains
have attracted particular interest in the /fi.liganancial sector, and several major banks have now
publicly explored the possibility of using consortium blockchains to store shared /fi.liganancial
records. One signi/fi.ligacant motivation is the billions of dollars they spend each year in resolv-
ing discrepancies between records that they maintain independently [/nine.lf/six.lf]. Another smaller
early adopter has been the diamond industry, in which several companies have turned to
blockchains to better track the movements of individual diamonds as they change hands
[/one.lf/seven.lf/five.lf]. Facebook has also recently designed a digital currency system (see section /two.lf./seven.lf) that
will be run by a consortium of technology companies, /fi.liganancial services companies, and
nonpro/fi.ligats. This digital currency system, Diem, is arguably the most high-pro/fi.ligale applica-
tion of consortium blockchains yet.
For something of an overview of proposed applications for permissioned blockchains, of
both the consortium and fully private varieties, one good resource is the United Kingdom
Government O/f\_f\_i.ligace for Science’s report, “Distributed Ledger Technology: beyond block
chain” [/one.lf/seven.lf/nine.lf]. Overall, the report expresses a high level of enthusiasm about the economic
/one.lf/nine.lf
Advantages of blockchains Disadvantages of blockchains
•May increase the availability and
integrity of applications
•May reduce reliance on trusted
third parties (less applicable to
private blockchains)
•May enable applications that, due
to a lack of trust in individual
services providers, it would
otherwise be unreasonable to use
(less applicable to private
blockchains)•Require greater computing
power, storage, and
communication
•May reduce the con/fi.ligadentiality of
records, unless sophisticated
cryptographic technologies are
applied
Table /three.lf: Some advantages and disadvantages of blockchains, in comparison with typical
centralized servers
implications of permissioned blockchains, describing them as the /fi.ligarst signi/fi.ligacant innova-
tion in ledger technology since ancient times.
Since its creation, Bitcoin has inspired the creation of many more permissionless RSMs.
Most of these implement fairly similar decentralized payment applications, but others
implement at least early versions of more sophisticated decentralized applications. There
are a number of applications, for instance, that aim to create decentralized markets that
allow users to buy storage space on one another’s computers. Perhaps most sophisticated
blockchain to follow Bitcoin so far, though, is Ethereum, which allows users to design and
implement arbitrary decentralized applications (see section /two.lf./one.lf/zero.lf).
Before moving on to describe the consensus protocols that allow permissionless block-
chains to work, let us attempt to brie/fl.ligay summarize the core features of blockchains. Com-
pared to the use of centralized servers to provide services, blockchains o/f\_f.ligaer a number of
advantages and disadvantages (see Table /three.lf).
As a /fi.ligarst advantage, blockchains can sometimes provide greater assurances of integrity
and availability. Whereas a single server might go o/f\_f\_l.ligaine, fall victim to a cyberattack,
or otherwise exhibit faulty behavior, it will typically be less likely that a large portion of
the nodes making up a permissioned blockchain will be faulty in the same way. Although
the degree of security associated with permissionless blockchains is still ambiguous (see
section /four.lf./two.lf./three.lf), in some cases they may also provide greater protection. In addition, if the
integrity of a blockchain’s log is compromised, then this will be much easier to detect than
a compromise to the integrity of a log that is not tamper-evident.
As a second advantage, blockchains can sometimes be used to reduce reliance on trusted
third parties to provide services. The users of consortium and permissionless blockchains
/two.lf/zero.lf
rely on large networks of actors, rather than one particular actor. For instance, whereas a
credit card user must rely on company such as Visa to process their transactions, Bitcoin
users do not rely on any single actor. In cases where trusted service providers hold an
undesirable degree of power, at least from certain users’ perspectives, this advantage can
be signi/fi.ligacant. A number of early adopters of Bitcoin, for example, saw it as a way to get
around restrictions credit card companies had placed on payments to WikiLeaks.
As a third advantage, blockchains can sometimes be used to provide services that it would
otherwise be unreasonable to trust a single actor to provide. Banks, for example, can use
consortium blockchains to store and automatically resolve discrepancies in their records
without needing to grant control over the records to any individual bank or third party.
As an important disadvantage, however, blockchains are much less e/f\_f\_i.ligacient than tradi-
tional centralized servers. Permissionless blockchains, in particular, are typically able to
process no more than a couple of dozen requests per second, and they typically consume
very large quantities of computing power, storage space, and bandwidth [/five.lf/four.lf, /six.lf/zero.lf]. These
limitations are due in large part to the fact that each individual node must store a complete
copy of the log and verify each new request. In general, the whole network can process re-
quests no faster than the least powerful device capable of serving as a node. One upshot,
then, is that any reasonably sophisticated or heavily used application cannot in practice be
run as a decentralized application. While decentralized payment applications are feasible,
even something so simple as a decentralized two-player chess program sits about at the
limits of what is currently possible. Decentralized versions of applications like Uber or
Facebook of course stand much further away still.
Developers are currently researching a number of potential ways to reduce these limi-
tations. Some permissionless blockchain projects that are still very new, at the time of
writing, also claim to have achieved substantial speedups without sacri/fi.ligacing security. In
general, though, it is an open question whether permissionless blockchain technology can
“scale” to accommodate large numbers of active users or applications that require very
frequently updated records (see section /four.lf./two.lf./one.lf).
As a second disadvantage, blockchains are naturally ill-suited for maintaining con/fi.ligadential
information. In the case of a permissionless blockchain, everyone in the world is granted
complete access to all of the records. Even in the case of a consortium blockchain, the
number of parties with complete access may still be greater than desired. Encrypting sen-
sitive records is only a limited solution, since the parties maintaining the blockchain must
still have access to enough information to determine whether a given record is valid. Ulti-
mately, those hoping to maintain con/fi.ligadential information on a blockchain may be forced
to rely on more sophisticated cryptographic technologies, such as “zero-knowledge proofs”
(see section /two.lf./eight.lf). The use of these technologies can further add to the cost and complexity
of record-keeping.
The next subsection will explore the consensus that enables permissionless blockchains in
greater detail. This next subsection is less essential to read than preceding sections, since
it focuses on how blockchains work rather than focusing on what blockchains do. These
/two.lf/one.lf
details are still quite helpful, however, for understanding e/f\_f.ligaorts to overcome the current
limitations of blockchain technology (see section /four.lf./two.lf).
/two.lf./six.lf./three.lf Consensus protocols
Although consensus protocols for permissioned blockchains remain an active research area,
practical protocols in this category have been known for decades. As mentioned in sub-
section /two.lf./six.lf./one.lf, these protocols can assure that permissioned blockchains will continue to
function as expected so long as at least two-thirds of their nodes behave properly.
The case of permissionless blockchains is more di/f\_f\_i.ligacult. If one naively attempts to adapt
these older protocols, then two major problems will stand out.
Sybil attacks: A dishonest party, if su/f\_f\_i.ligaciently motivated, might carry out
what is known as a Sybil attack by setting up many di/f\_f.ligaerent “sock puppet”
nodes in order to arti/fi.ligacially increase their in/fl.ligauence on block creation.
Lack of incentives for honesty: Since the parties involved in running nodes
are not pre-selected, there may be no basis for expecting them to vote hon-
estly.
In response, the consensus protocols for permissionless blockchains provide two corre-
sponding solutions.
Tying voting power to scarce resources: Voting power is made proportional
to demonstrated ownership of scarce resources. For example, it is possible
to make voting power proportional to computing power by requiring voters
to provide solutions to computationally intensive puzzles. Then, no one can
in/fl.ligaate their in/fl.ligauence beyond the amount of computing power they possess.
Rewarding honesty with digital currency: Voters are incentivized to vote
honestly by rewarding them with a quantity of digital currency, to be recorded
in the blockchain, if they vote for blocks that the network ultimately con-
verges on (or costing them digital currency if they do not). By this mecha-
nism, a state of a/f\_f.ligaairs in which each node expects the network to converge
on honest blocks is likely to be stable.
If this description is still overly mysterious, then the following bullet points provide more
detail, describing the working of a somewhat typical permissionless blockchain, along the
lines of Bitcoin [/one.lf/one.lf/nine.lf]. Note, though, that this description is not meant to describe how all
permissionless blockchains work and glosses over a handful of subtleties.
•There is some network that anyone is free to join, along with some software asso-
ciated with the blockchain that anyone is free to run. The software implements a
protocol that describes under what conditions a request sent through the network
is valid. Users who maintain a full copy of the log and run the software are said to
be running full nodes .
/two.lf/two.lf
•The blockchain supports a payment application, which tracks the ownership of a
digital currency known as a “cryptocurrency.” Among the requests that the block-
chain can process are requests to send currency from one account to another.
•When users submit requests, they must pay cryptocurrency fees. These fees are ex-
tracted from their accounts when requests are processed.
•Each person running a full node maintains a backlog of the requests they have re-
ceived since they last added a block to their copy of the log. Someone running a full
node is said to be honest if they are indeed using a copy of the correct software and
are, therefore, only processing requests if they are valid. Honest users also do not
send contradictory requests to other members of the network.
•Some subset of users running full nodes also compete to solve brute force computa-
tional puzzles generated on the basis of the previous block’s contents. These users are
known as miners . The odds that a given miner will solve a puzzle /fi.ligarst is proportional
to the quantity of computing power they direct at the puzzle. When a miner does
solve a puzzle /fi.ligarst, they turn their backlog into a new block, B, which they add to
their current version of the blockchain. They are also permitted to write and process
a special request to deposit a cryptocurrency reward into their own account. Some
or all of this reward is derived from the fees paid by the users whose requests are
included in the new block. These fees incentive miners not just to solve puzzles, but
also to process all of the valid requests they receive. Part of the miner’s reward may
also include some new quantity of cryptocurrency that was not previously owned
by anyone.
•The miner who solves a puzzle /fi.ligarst advertises their new block, B, to the others in
the network. The other full nodes either add Bon to their individual copies of the
blockchain, if it is consistent with the earlier blocks in their copies, or ignores it, if
it is not consistent.
•If, after at least nintervals, Bis part of the longest consistent version of the block-
chain being proposed, then Band the blocks preceding it are generally acknowledged
to be conﬁrmed . This is partly a social phenomenon, in the sense that it concerns the
manner in which people assign the contents of a blockchain practical signi/fi.ligacance.
•If it is the case that, a su/f\_f\_i.ligaciently large portion of the time, the person who gains
the ability to create a new block is honest, then if nis su/f\_f\_i.ligaciently large, it follows
that it is overwhelmingly likely that only blocks containing valid records will be
con/fi.ligarmed and that they will remain con/fi.ligarmed into the future./one.lf/four.lfDue to the fact
that the rewards that successful miners grant themselves will only be con/fi.ligarmed if
the blocks they propose are also con/fi.ligarmed, it also follows that miners have strong
/fi.liganancial incentives to be honest.
It is worth noting that, in protocols of this form, there is not really any decisive moment
in which a “vote” occurs. Rather, the nodes simply take turns proposing blocks, and, over
/one.lf/four.lfIntuitively, it seems as though the “su/f\_f\_i.ligaciently high proportion of the time” ought to include anything above
/five.lf/zero.lf%. In fact, for somewhat technical reasons having to do with the potential to cause confusion by reporting
con/fl.ligaicting records to di/f\_f.ligaerent members of the network, the bar may be as high as /seven.lf/five.lf% [/six.lf/four.lf].
/two.lf/three.lf
time, it becomes increasingly clear whether the other nodes are predominantly building
on top of a given block or ignoring it. Eventually, if a block is buried deep enough in the
longest proposed version of the blockchain, then its contents are taken to represent part
of the “con/fi.ligarmed” history of records./one.lf/five.lf
The particular protocol sketched above ties the frequency with which a node can propose
blocks to the computing power it applies to puzzles. But this is only one of two main
approaches to basing in/fl.ligauence on scarce resource ownership [/two.lf/zero.lf]:
•The selection of block-creating nodes on the basis of computing power, as described
in the above protocol, is known as proof of work (PoW) . Users known as “miners”
demonstrate their ownership of computing power by competing to solve computa-
tionally di/f\_f\_i.ligacult puzzles that are generated on the basis of the previous block’s hash.
Whoever solves the problem /fi.ligarst gains the ability to create a new block, and the
probability that a user solves the problem /fi.ligarst will be proportional to the amount
of computing power they direct at it.
•The selection of block-creating users on the basis of digital currency ownership
is known as proof of stake (PoS) . In a PoS system, the probability that a user is se-
lected depends on the amount of cryptocurrency they have deposited (relative to
the amount of cryptocurrency deposited by other users).
Proof of work is currently widely used, including in Bitcoin. Proof of stake is less commonly
used, but has attracted growing interest, in part because it avoids the need to devote huge
amounts of electricity to solving mining puzzles. Since some estimates have placed the
total electricity consumption of Bitcoin miners as roughly on par with that of the entire
country of the Netherlands, and since the costs borne by miners can lead to very high
transaction fees for users submitting records, decreasing electricity consumption is a high
priority [/one.lf/three.lf/eight.lf]./one.lf/six.lf
One particularly valuable feature of both PoW and PoS is that, in practice, they create ad-
ditional /fi.liganancial incentives for the most in/fl.ligauential users to be honest. This is because, to
obtain a signi/fi.ligacant level of in/fl.ligauence, these users must have invested heavily in specialized
hardware or in the relevant digital currency. If they were to undermine trust in the rel-
evant blockchain through dishonest block proposals, then the value of their investments
could evaporate.
In addition, PoW schemes have the added bene/fi.ligat of associating concrete physical costs
with the generation of blocks. The further back a record is in the longest version of the
blockchain, the more electricity would need to be expended to go back and make an equally
long version where that record is absent or replaced.
/one.lf/five.lfIn fairly rare cases, more than one proposed version of a blockchain can take on social signi/fi.ligacance. Such an
event is known as a forkof the blockchain. Forks normally occur when some subset of users decide they would like
to adopt a new set of standards for adding new records or forming blocks, while retaining the previous records.
In the long run, forks also imply the emergence of two independent cryptocurrencies.
/one.lf/six.lfAnother bene/fi.ligat of proof-of-stake systems is that they may allow transactions to be con/fi.ligarmed more quickly.
There is no need to wait for a sequence of mining puzzles to be solved.
/two.lf/four.lf
/two.lf./seven.lf Cryptocurrency
Adigital currency , generally, is a form of currency that consists of balances recorded in
electronic databases. PayPal credit and video game money serve as two now-mundane
examples.
Although de/fi.liganitions vary, we will de/fi.ligane cryptocurrencies as digital currencies whose own-
ership is tracked and transferred using decentralized or consortium-backed applications.
Bitcoin is the most prominent example. In most cases, including the case of bitcoin,
the relevant application is decentralized and relies on the use of a permissionless block-
chain.
Cryptocurrencies are objects of interest in their own right. However, as discussed above,
cryptocurrencies also play important roles in consensus protocols for permissionless block-
chains. They both enable permissionless blockchains and, in many cases, are themselves
enabled by permissionless blockchains.
A simpli/fi.ligaed cryptocurrency system, similar to the one associated with Bitcoin, might work
in the following way [/one.lf/one.lf/eight.lf, /one.lf/one.lf/nine.lf].
•A cryptocurrency is associated with a permissionless blockchain.
•At any given time, the currency is divided up into discrete units known as coins,
which are understood to be owned by individual users of the currency. Users possess
pairs of cryptographic keys, with their public keys serving as pseudonyms./one.lf/seven.lf
•A coin of value Vis minted (or “mined”) if a record of form “A new coin of value
Vis granted to X” is added to the blockchain’s log, where Xis the public key of
whichever user will own the coin. Users can only mint coins if they have just created
a new block, as part of the reward for their work.
•Say that a user with public key Xwould like to give a coin of value Vto a user with
public key Y. To do this, they can simply submit a record of form “ Xgives Ya coin
of value V” to the blockchain, along with their digital signature. The record will
be classi/fi.ligaed as valid, and therefore be added to the log, so long as these conditions
obtain: there is a previous record granting Xthe coin, there is no subsequent record
showing that Xgave the coin away already, and X’s signature is correct./one.lf/eight.lf
Variations on this system might associate a certain public key with a “central bank” that
can mint new coins, or might allow new coins to be created on the basis of a complex
voting process. In principle, there is a great deal of /fl.ligaexibility in how a cryptocurrency
system might be designed. However, in practice, most systems are not very di/f\_f.ligaerent than
the simple idealized system just sketched.
/one.lf/seven.lfAs a technical note, it is more common in practice to produce pseudonyms by taking the hashes of public
keys (known as addresses ). This is because public keys can be quite long.
/one.lf/eight.lfThe step of verifying that a coin has not already been spent is what implies the need for a complete log of
previous transactions. While a traditional digital currency system solves the double-spending problem by relying on
a trusted third party to maintain the log, a cryptocurrency system achieves a greater degree of decentralization
by using a permissionless blockchain instead.
/two.lf/five.lf
A core appeal of cryptocurrencies is that they can function as a sort of borderless, digital
cash. Assuming the system is not set up with some more complicated set of rules restrict-
ing valid transactions, any user can send cryptocurrency to any other user anywhere else in
the world, without needing to go through institutions like banks or credit card companies.
This makes cryptocurrencies perhaps most obviously appealing to people who lack access
to such institutions (often referred to as the “unbanked”) or who are distrustful of them
[/one.lf/seven.lf/three.lf, /nine.lf/seven.lf]. The absence of /fi.liganancial intermediaries in cryptocurrency transactions also, in
many cases, allows for unusually low transaction fees. For this reason, cryptocurrencies
are sometimes used as a low-cost alternative to overseas transfers and local currency ex-
changes./one.lf/nine.lfIn addition, cryptocurrencies may allow users to get around political restric-
tions on the use of traditional payment services. Cryptocurrencies have been used, for
example, to make payments in online black markets like the “Silk Road” and to sustain
WikiLeaks after major credit card companies blocked payments to it [/one.lf/one.lf/one.lf].
As stated above, the /fi.ligarst successful cryptocurrency was bitcoin, which was launched /two.lf/zero.lf/zero.lf/nine.lf
and is maintained through a proof-of-work protocol. In the bitcoin system, as in the sim-
pli/fi.ligaed system described above, additional quantities of the currency come into existence
whenever users create blocks, and anyone is free to send or receive currency using an in-
de/fi.liganite number of public-key pseudonyms. The initial user base for bitcoin had a strongly
libertarian or self-identi/fi.ligaed “crypto-anarchist” bent, drawn largely by an interest in un-
dercutting /fi.liganancial institutions [/one.lf/three.lf/one.lf]. However, over time, the currency has slowly crept
further into mainstream use, although mostly as an investment rather than as a means of
exchange. At the time of this writing, several hundred billion dollars’ worth of bitcoin
exists.
Many other cryptocurrencies have also been created since /two.lf/zero.lf/zero.lf/nine.lf, although at the moment
only a few have market caps or users bases of comparable size. Some of these cryptocur-
rencies are associated with blockchains that o/f\_f.ligaer just slight variations on Bitcoin’s design.
Others, such as Ether (discussed in section /two.lf./one.lf/zero.lf), are associated with blockchains that aim
to provide services beyond payment processing; in these cases, the cryptocurrency’s role as
a necessary design element is perhaps more important than its role as a store of value or
medium of exchange.
One interesting question, which may seem in need of answering, is the question of how
cryptocurrencies come to be accepted as having monetary value. For most cryptocurren-
cies, the simple answer is that, like traditional /fi.ligaat currencies, they are accepted as having
monetary value because some initial portion of people accept them as having monetary
value. For example, bitcoin has value because some businesses are willing to accept it as
payment and because some currency exchanges are willing to exchange it for more estab-
lished currencies such as US dollars.
For other cryptocurrencies, however, the answer is slightly more complicated. The value
of astablecoin is linked to the value of some other asset, such as the US dollar or gold. The
most straightforward way for the developers of a cryptocurrency to establish this link is
/one.lf/nine.lfHowever, anyone converting a cryptocurrency payment back into their local currency will still need to pay
some non-negligible fee.
/two.lf/six.lf
to set up an organization that pledges to exchange units of the cryptocurrency for units
of the asset at some /fi.ligaxed rate. For instance, an organization that supports a gold-backed
cryptocurrency might buy up a large quantity of gold, then pledge to accept any o/f\_f.ligaers to
exchange Ncoins for Npounds of gold. Stablecoins whose stability is achieved through
this method are known as asset-backed cryptocurrencies ./two.lf/zero.lf
The key advantage of stablecoins, unsurprisingly, is that the purchasing power of indi-
vidual coins will be stable so long as the value of the linked asset is stable. As a point of
comparison, it is common for the purchasing power of an individual bitcoin to rise or fall
by more than a factor of two within an individual year. These sorts of radical swings have
led most people to treat bitcoin primarily as a risky investment, which has some chance of
skyrocketing in value if held for long enough, rather than treating it as a regular currency
that can be used to make casual purchases./two.lf/one.lf
The main downside of asset-backed stablecoins, at least from the perspective of more
libertarian-minded cryptocurrency supporters, is that they miss much of the original “point”
of cryptocurrencies. Asset-backed cryptocurrencies are not as decentralized as traditional
cryptocurrencies, such as bitcoin, because they rely on a backing organization with sub-
stantial power over the coin’s value. The behavior of this backing organization is likely to
be highly regulated by traditional /fi.liganancial institutions, and the asset it uses to back the
cryptocurrency is likely to be deeply intertwined with traditional /fi.liganancial institutions as
well.
Nonetheless, due to the use of blockchain technology, even an asset-backed coin may come
with an unusually strong guarantee that no one can easily block transactions or alter ac-
count balances. Diem, a high-pro/fi.ligale asset-backed cryptocurrency project initiated by
Facebook, illustrates the advantage of this feature [/one.lf/zero.lf/seven.lf]. Due to low public trust in many
countries, Facebook would probably have a rather di/f\_f\_i.ligacult time if it attempted to push for
the widespread adoption of a digital currency that it managed using its own servers. The
use of a blockchain, in this case a consortium blockchain, reduces the need for the users of
Diem to place any trust in Facebook itself.
Although there is much more that can be said about cryptocurrency systems, I will close
this section by summarizing some of their disadvantages when compared to more cen-
/two.lf/zero.lfThere are also other, less popular methods of tying the value of a cryptocurrency to the value of another asset.
For example, if a cryptocurrency system grants some particular central-bank-like user the authority to mint or
destroy coins, then they can use their powers to target a particular exchange rate. The value of individual coins,
relative to the external asset, will tend to grow when existing coins are destroyed and shrink when new coins
are minted. This process of minting and destroying coins, in order to cancel out any temporary shifts in the
exchange rate, can also be automated through the use of some algorithm that is implemented by the blockchain
itself. However, even in this case, there will still be a need for some trusted user or network of users to be given
special authorities: someone needs to be trusted to input accurate information about the current exchange rate.
The Ampleforth project, for instance, uses an “oracle system made up of whitelisted independent data providers”
to input exchange rate data into its blockchain [/one.lf/zero.lf/four.lf].
/two.lf/one.lfThe vast majority of companies still do not accept cryptocurrency payments. Nonetheless, the number of
companies that do accept cryptocurrency payments is growing. Tesla, for instance, has given customers the option
of using bitcoin to buy cars. PayPal has also announced plans to support cryptocurrency use, albeit not “direct”
use, by making it easy to convert cryptocurrency back into /fi.ligaat currency at the point of purchase.
/two.lf/seven.lf
Advantages of cryptocurrencies Disadvantages of cryptocurrencies
•Lower institutional barriers to
use
•Typically lower transaction fees
•Reduced reliance on and need to
trust traditional /fi.liganancial
institutions
•More con/fi.ligadentiality, if further
cryptographic techniques used•Typically slower transaction
processing speeds (and maximum
transaction volumes)
•Encourage hoarding behavior, if
not tied to the value of another
asset
•Place burden of security more
strongly on end-user
•Less con/fi.ligadentiality, if no further
cryptographic techniques used
Table /four.lf: Advantages and disadvantages of cryptocurrencies, in comparison with central-
ized payment applications
tralized payment services like those o/f\_f.ligaered by credit card companies (see Table /four.lf). These
comments will focus on decentralized cryptocurrency systems, rather than cryptocurrency
systems supported by permissioned blockchains, both because their disadvantages are es-
pecially large and because they represent an especially large break from familiar payment
systems.
First, particularly for cryptocurrencies built on permissionless blockchains, commonly
used distributed consensus protocols can create inconvenient delays between a user propos-
ing a payment and the network con/fi.ligarming it (see section /two.lf./six.lf./three.lf). Second, since most exist-
ing permissionless blockchains can process no more than a couple of dozen transactions
per second (see sections /two.lf./six.lf./two.lf and /four.lf./two.lf./one.lf), most decentralized cryptocurrencies currently
face fairly hard ceilings on how much payment activity they can support. The result of
these ceilings can be to drive up transaction fees if too many users would like to make
transactions at once./two.lf/two.lfThird, cryptocurrencies which are not asset-backed generally have
highly volatile exchange rates and are de/fl.ligaationary, thereby incentivizing hoarding be-
havior rather than spending behavior./two.lf/three.lfFourth, cryptocurrency users must typically take
/two.lf/two.lfIn the case of Bitcoin, for example, transactions take about an hour on average to be con/fi.ligarmed. Greater
transaction volume has also led the average transaction fee to grow to several dollars, or even dozens of dollars
in boom periods, although a typical fee used to be only a few cents. Fortunately, a number of second-wave
cryptocurrencies (such as Litecoin) process transactions several times faster and, due to their faster processing
speeds and smaller userbases, currently require smaller transaction fees. At the time of writing, a number of
newly developed permissionless blockchains, underpinned by novel consensus protocols, have begun to advertise
processing speeds thousands of times greater than Bitcoin. These newer projects and the questions that still
surround them will be discussed in section /four.lf./two.lf./one.lf.
/two.lf/three.lfOne view on this point is that the tendency for non-asset-backed cryptocurrencies to induce hoarding be-
havior means that they should not actually be thought of as currencies. A key feature of a currency is that the
people who hold it should often use it to make purchases. Arguably, then, cryptocurrencies like bitcoin are less
analogous to traditional currencies than they are to rare paintings. Like rare paintings, these cryptocurrencies are
exotic assets that investors sometimes use as alternatives to traditional /fi.liganancial assets; their valuations depend
/two.lf/eight.lf
greater responsibility for the security of their holdings than users of traditional currencies.
A cryptocurrency owner who loses their own private key will have absolutely no way to use
their coins, and a cryptocurrency owner whose private key is discovered by someone else
will have no way to reverse any fraudulent transactions; the additional security features
o/f\_f.ligaered by credit card companies, for example, can o/f\_f.ligaer a very large amount of value to
users. Finally, just as blockchains are naturally less suited to con/fi.ligadentiality than central-
ized servers (see section /two.lf./six.lf./two.lf), cryptocurrency transactions can often be less con/fi.ligadential
than transactions made using traditional payment services.
This /fi.liganal point may be surprising, sometimes it is sometimes claimed that cryptocurren-
cies like bitcoin allow users to make anonymous payments. In fact, bitcoin is pseudonymous ,
since payments are still attached to unique public-key pseudonyms, and this distinction
makes all the di/f\_f.ligaerence [/one.lf/one.lf/nine.lf]. Every payment that a given user’s pseudonym makes or
receives is logged for anyone else to see, and law enforcement agencies (and other users)
have found it easy to attach pseudonyms to real-world identities by analyzing patterns of
payments [/one.lf/three.lf/four.lf]. In addition, if the user does not use an anonymizing service such as Tor,
then it may even be possible to associate their pseudonym directly with their device’s IP
address. Finally, and perhaps most importantly, users who would like to exchange crypto-
currency for some good or service in the physical world will still normally need to expose
some aspect of their identities to whoever they are interacting with. Bitcoin, in short, is
not very private.
On the other hand, some recently developed techniques for obscuring transactions hint
that the long-term trend may be toward much greater privacy for cryptocurrency users.
These include “mixing services,” which allow users to swap coins in order to frustrate
network analysis, and “state/payment channels,” which allow sets of users to conduct se-
quences of transactions and then only publish the /fi.liganal outcomes of these transactions./two.lf/four.lf
However, the most promising techniques, now to be discussed, are almost certainly those
that rely on cryptographic tools known as zk-SNARKs.
/two.lf./eight.lf Zero-knowledge proofs
Zero-knowledge proofs are proofs of mathematical statements that do not convey any infor-
mation other than that the statements are true (and that, as a logical consequence, the
prover has the knowledge necessary to prove them) [/eight.lf/zero.lf].
As an illustration, consider the question of whether there is a path around the graph de-
picted in Figure /four.lf that touches each node exactly once. Typically, the way to prove to
another party that such a path exists is to share one such path, as Figure /four.lf does, and al-
low them to check that it meets the criterion. In contrast, a zero-knowledge proof would
on opaque and sometimes ba/f\_f\_l.ligaing social dynamics, and it would be unusual to use them to buy some milk at the
store.
/two.lf/four.lfCurrently, the most popular cryptocurrency designed to obscure transaction details is Monero. It applies
“ring signatures,” another cryptographic technology, to introduce uncertainty about the origins of payments.
Some research suggests that the level of privacy o/f\_f.ligaered by Monero, while greater than that o/f\_f.ligaered by Bitcoin, is
still relatively low [/one.lf/one.lf/six.lf].
/two.lf/nine.lf
Figure /four.lf: There is a path around this graph that touches each node exactly once. A typical
proof of this statement requires sharing the details of at least one such path (as in the
above /fi.ligagure). In contrast, a zero-knowledge proof does not require sharing any additional
information of this sort. (Image by Christoph Sommer.)
not require any particular path to be shared. The only information that a zero-knowledge
proof communicates is the simple fact that whatever statement it is meant to prove is
true./two.lf/five.lf
Zero-knowledge proofs were /fi.ligarst described in a /one.lf/nine.lf/eight.lf/five.lf paper. Since this time, cryptogra-
phers have discovered that all mathematical statements that it is practical to prove at all
can also be proven in zero-knowledge [/one.lf/six.lf]./two.lf/six.lf
Zero-knowledge proofs can be divided into interactive and non-interactive varieties [/two.lf/four.lf].
In the interactive variety, a prover andveriﬁer engage in back-and-forth interactions that
ultimately serve to convince the veri/fi.ligaer that the relevant statement is true. In the non-
interactive variety, which has been more recently developed, the prover simply publishes
a proof that anyone is free to verify. While interactive proofs only serve to prove a given
statement to one particular party at a time, non-interactive proofs can be used to prove
statements to large masses of parties at once.
One recent event of note is the development of zk-SNARKs (“zero-knowledge Succinct
Non-interactive ARguments of Knowledge”) in /two.lf/zero.lf/one.lf/zero.lf. These are a variety of non-interactive
/two.lf/five.lfThe de/fi.liganition of a zero-knowledge proof can also be given more formally. Suppose there is some function
V(X,w) that determines whether some information w, known as a witness , su/f\_f\_i.ligaces to prove some mathematical
statement X. In a typical proof, the prover shares a witness with veri/fi.ligaers, who then compute V(X,w) to determine
that Xis true. In contrast, a zero-knowledge proof is a proof in which the prover demonstrates that they possess a
witness of the relevant statement without actually sharing the witness. For above case, Xwould be the statement
that the given kind of path around the graph exists, wwould be a description of a path, and Vwould be a function
that checks whether the path is valid and touches each node exactly once.
/two.lf/six.lfSpeci/fi.ligacally, as another technical note, anything in the complexity class PSPACE can be proven in zero-
knowledge.
/three.lf/zero.lf
zero-knowledge proofs that are particularly short, e/f\_f\_i.ligacient to check, and therefore practi-
cal to use [/one.lf/eight.lf].
One application of zk-SNARKs, already alluded to, is in developing cryptocurrency sys-
tems that allow users to prove the validity of the payments they record on the blockchain,
without also publicly revealing sensitive information that implies the payments’ recipients,
values, or origins [/one.lf/four.lf/one.lf]. The /fi.ligarst example zk-SNARKs being used in this way is Zcash, a
cryptocurrency developed by American and Israeli academics and launched in late /two.lf/zero.lf/one.lf/six.lf.
Developers have also been gradually rolling out tools to facilitate the use of zk-SNARKs
on Ethereum, one of the most widely used blockchains [/seven.lf]. It could be only a matter of
time until the typical cryptocurrency transaction truly is private [/one.lf/three.lf/five.lf]./two.lf/seven.lf
Another application of zk-SNARKs is in developing what Joshua Kroll refers to as account-
able algorithms [/one.lf/zero.lf/three.lf]. In a recent paper, Kroll describes a general protocol that can be used
to provide accountability in any case where an institution is using an algorithm to make
decisions that a/f\_f.ligaect individuals. Examples of such cases include the use of algorithms,
applied to personal data, to select individuals for search or for tax auditing. In Kroll’s
protocol, the use of zk-SNARKs achieves two ends. First, zk-SNARKs allow a/f\_f.ligaected in-
dividuals to verify that the algorithm has received the approval of an auditing body and
meets certain other criteria, without needing to learn the details of the algorithm. Second,
zk-SNARKs allow an auditing body to verify that the algorithm they have approved is in
fact being used to make decisions, without needing to learn what these decisions are or
the personal data used to make them. The ultimate e/f\_f.ligaect of schemes such as Kroll’s could
be to increase public trust in institutions, while decreasing corruption and opening up the
procedures followed by these institutions to greater scrutiny.
It should be noted, however, that the use of zk-SNARKs does come with some downsides.
First, zk-SNARKs will always be somewhat less e/f\_f\_i.ligacient than traditional proofs. Second,
the use of zk-SNARKs requires an initial trusted setup procedure in which a set of parties
generate information that is a necessary input when constructing zk-SNARKs [/one.lf/nine.lf]. This
procedure also generates some secondary information, informally known as “toxic waste,”
that could be used to construct fraudulent zk-SNARKs. The parties who participate in the
setup procedure must take great pains to demonstrate that they have destroyed this “toxic
waste,” rather than saving it to exploit it later [/one.lf/six.lf/four.lf]./two.lf/eight.lf
Another recent development of note is a series of recent proposals for practical applica-
tions of what are known physical zero-knowledge proofs [/six.lf/eight.lf]. These are protocols that ap-
/two.lf/seven.lfOn the other hand, there is also some evidence that user interest in strong privacy features is fairly low.
Bitcoin remains more popular than Zcash even among people actively engaged in criminal activity [/one.lf/four.lf/nine.lf]. Fur-
thermore, only a minority of Zcash’s current users choose to use its (optional) privacy features. It is possible that
many potential users of Zcash’s zk-SNARK technology either do not understand or do not trust its ability to
protect their privacy.
/two.lf/eight.lfOf note, however, is some recent research into another variety of non-interactive zero-knowledge proofs, zk-
STARKs , that would lack this vulnerability [/one.lf/seven.lf]. Currently, the main downside of zk-STARKs over zk-SNARKs
is that zk-STARKs are substantially longer. As of /two.lf/zero.lf/one.lf/eight.lf, according to the original zk-STARK paper, they require
about one thousand times more storage space. This di/f\_f.ligaerence in storage requirements is especially important
in the context of traditional blockchain-based applications, given the need for many di/f\_f.ligaerent users to store
complete transaction records.
/three.lf/one.lf
ply the principles of interactive zero-knowledge proofs to the demonstration of physical
(rather than mathematical) claims.
Consider the following illustration. Alice would like to prove to Bob that two cups contain
the same number of balls without revealing what this number is. To do this she can /fi.ligall
up a bucket with another number of balls, known only to her, then make a commitment by
stating how many balls will be in the bucket if she pours either cup in. She allows Bob to
challenge her by picking, at random, one of the two cups to pour in. Then, as a response ,
she shows Bob how many balls are now inside the bucket. Since her initial statement
would have had only a /five.lf/zero.lf% chance of being correct if the cups were unequal, the result
of this procedure should increase Bob’s con/fi.ligadence in their equality. The procedure can
be repeated until Bob’s con/fi.ligadence reaches any given threshold. In this way, Alice can
prove her proposition about the balls in the cups (probabilistically) while still keeping
their quantity a secret.
While physical zero-knowledge proofs were /fi.ligarst described primarily for pedagogical pur-
poses, helping to illustrate how non-interactive zero-knowledge proofs might be possible,
it is now clear that they can have signi/fi.ligacant practical applications in their own right.
A /two.lf/zero.lf/one.lf/four.lf paper, published in Nature , showed that physical zero-knowledge proofs can be
used to verify that a country is disposing of a genuine nuclear warhead, without needing
to learn the design details of this warhead [/seven.lf/six.lf]. It has since been shown that it is also
possible to verify that a given suspect’s /fi.ligangerprints or DNA do not match those found at
a crime scene, without needing to collect their /fi.ligangerprints or DNA [/six.lf/eight.lf].
Since very few academics have ever written on physical zero-knowledge proofs, it is plau-
sible that many more applications remain to be found.
/two.lf./nine.lf Smart property
Cryptocurrency is not the only form of property whose ownership can be tracked or de-
termined with blockchains.
As a very closely related use case, a blockchain’s users might also create tokens , whose own-
ership is recorded in just the same way cryptocurrency ownership is. Users can sell the
tokens to others with the promise that these tokens will be exchangeable for a particular
service in the future. It is reasonable to think of these tokens as being roughly analogous
to the tokens sometimes sold at arcades (which can be exchanged for a certain number of
rounds of play at speci/fi.ligac games). Alternatively, users may sell tokens purely as collecta-
bles, which are valued for roughly the same reasons that rare stamps are valued. Unique
tokens, known as non-fungible tokens (NFTs ), have in some cases sold for millions of dollars
[/one.lf/five.lf, /six.lf/three.lf]./two.lf/nine.lf
/two.lf/nine.lfAn NFT is typically associated with some piece of digital media. For example, an artist may assert that an
NFT, in some sense, “represents” a particular animation that they have made. At /fi.ligarst glance, the valuations of
certain NFTs are rather confusing. However, one should keep in mind, they are at most slightly more confusing
than the valuations of many other collectables.
/three.lf/two.lf
As another well-known case, traditional property records, which might otherwise be stored
in another form of database, can of course also be stored using a blockchain. For example,
at least as of /two.lf/zero.lf/one.lf/eight.lf, the Ghanaian national government has been considering a joint project
with IBM to place local land deeds on blockchains in order to lower the risk of meddling
by corrupt o/f\_f\_i.ligacials [/five.lf/eight.lf].
The link between blockchain-based records and property ownership can also be made
much more concrete, however, through the creation of smart property : devices with elec-
tronic components that facilitate the transfer of their ownership [/one.lf/five.lf/nine.lf, /one.lf/one.lf/nine.lf].
Consider the following system:
•The device is initially associated with some public key, which belongs to the device’s
owner. This ownership is logged as a record on the blockchain, which the device can
read.
•To unlock or operate the device, its owner must send a message to the device and
digitally sign it with their private key. They may send this message through a channel
such as a Bluetooth connection or a card reader slot.
•Say that the owner has public key X, another person has public key Y, and the device
is denoted by D. If the owner would like to give the device to the person with public
keyY, then they can add a record of form “ Xgives DtoY” to the blockchain, along
with their digital signature. Now the device will respond to messages signed by the
new owner and will no longer respond to messages signed by the old one.
To make this description tangible, we can imagine that the device is a car, and that the car
will only unlock or start if it receives a message signed with the correct key. More limited
access rights (such as the right to use the car only on a certain day) could also be granted
through a similar scheme.
With the rise of the internet of things (IoT), or the trend of more and more electronic de-
vices having internet connections, it seems like the large-scale implementation of physical
smart property could be feasible [/four.lf/eight.lf]. This implementation could be achieved using per-
missionless blockchains or consortium blockchains maintained by the devices’ producers.
The advantage of using such blockchains, here, is that it would be unreasonable in any
other case to trust a single actor with running an application that directly controls a wide
swath of physical property./three.lf/zero.lf
However, it remains to be seen whether there will be any signi/fi.ligacant consumer interest in
smart property. As with cryptocurrency, some users might be attracted by the idea that
smart property can reduce reliance on centralized institutions that track property own-
ership or protect property from theft. Smart property might also o/f\_f.ligaer value by reducing
ine/f\_f\_i.ligaciencies in transactions and consolidating records of ownership. On the other hand,
one could argue that there is not much hardship involved in (e.g.) transferring the owner-
ship of a car in the traditional way.
/three.lf/zero.lfMore broadly, a number of companies are also investigating the advantages of using blockchains to provide
greater security for their own IoT devices.
/three.lf/three.lf
We should note that essentially the same privacy concerns that exist for cryptocurren-
cies exist for smart property too. Any smart-property transactions implemented on the
most widely used permissionless blockchains today would be highly visible (although fu-
ture systems using zk-SNARKs may be able to o/f\_f.ligaer more privacy), and even specialized
consortium blockchains might present greater privacy concerns than less comprehensive
centralized databases. This would seem to be an important limitation.
Finally, it is worth noting that systems of property ownership and exchange that are more
complex (and less decentralized) than the one described above could also be designed.
For example, we can imagine a smart-property car for which, by design, a government-
held private key is always capable of shutting down or transferring ownership, should an
appropriate legal order be given.
/two.lf./one.lf/zero.lf Smart contracts
Asmart contract , broadly de/fi.liganed, is a contract whose execution is automated to a signi/fi.liga-
cant extent.
Vending machines provide a simple illustration. When someone places money into a vend-
ing machine and receives a candy bar in return, the machine is, in e/f\_f.ligaect, executing a con-
tract between the buyer and seller.
The concept of a smart contract was /fi.ligarst formulated by Nick Szabo in /one.lf/nine.lf/nine.lf/six.lf, who argued
that, beyond o/f\_f.ligaering e/f\_f\_i.ligaciency gains, smart contracts can be used to reduce the role of
trust in contract execution [/one.lf/five.lf/nine.lf]. If a contract can be enforced automatically, and the
relevant mechanism can be made su/f\_f\_i.ligaciently transparent and resistant to tampering, then
the parties to a contract will not need to trust the other to execute their end of it; they will
also not need to trust any third party to act as an intermediary or enforcer.
By enabling applications whose execution does not rely on trusted third parties, consor-
tium and permissionless blockchains may o/f\_f.ligaer a particularly ideal platform for imple-
menting smart contracts./three.lf/one.lf
Consider, for example, the simple case of a decentralized application for playing chess:
Players take turns submitting moves, and a digital currency deposit is automatically trans-
ferred from the loser to the winner. This application is, in e/f\_f.ligaect, executing a contract
between the players. Here, though, there is no need to trust the loser to hand money over
to the winner, an escrow service to handle the transfer, or a court to extract compensation
for dishonesty.
The topic of smart contract design received a major boost in /two.lf/zero.lf/one.lf/three.lf, when Vitalik Buterin
proposed an in/fl.ligauential design for a blockchain known as Ethereum. Finally launched in
/two.lf/zero.lf/one.lf/five.lf, Ethereum o/f\_f.ligaers its users the ability draft and execute any smart contract that can
be expressed in terms of the blockchain’s state.
/three.lf/one.lfUnless otherwise stated, the use of the term “smart contract” throughout the rest of the report can be assumed
to refer to a smart contract implemented using a consortium or permissionless blockchain.
/three.lf/four.lf
To gain some intuition of how this can work, consider the following (highly idealized)
description of a smart contract’s creation and execution:
•Suppose a user with public key Xwould like to sell a smart-property car, denoted
byD, to a user with public key Y, at the cost of Vunits of cryptocurrency.
•To accomplish the transaction, the seller can submit a contract of this form: "If X
andYboth submit signed messages approving the transaction, then transfer DtoY
and a coin of value VtoX." This contract is then logged. If both the buyer and the
seller proceed to submit messages of approval, signed with their respective private
keys, then it will be recorded that the ownership of the two items has switched.
•The seller gains the ability to spend the coin, and the buyer gains the ability to
operate the car and demonstrate that it is rightfully theirs. The trade has been ac-
complished, without any need for a trusted intermediary and without any risk of
either participant failing to follow through.
Naturally, the conditions for transferring an item through a blockchain-based smart con-
tract can only be expressed in terms of information that is stored in the blockchain. How-
ever, this does not make it impossible to set conditions that depend on the external world.
Say that two users would like to enter into a bet about the high temperature for tomorrow.
A simple way to carry this bet out would be to write a smart contract that will transfer
cryptocurrency, automatically, when a certain trusted friend submits a signed report to
the blockchain. Trusted services could also be set to print information about the weather
onto the blockchain to facilitate weather-related contracts.
In addition, there are some new or emerging services that use a mixture of reputation sys-
tems and consensus protocols, associated with conditional payments, to incentivize users
to provide reliable inputs to others’ smart contracts. These services are known as decentral-
ized oracle systems , and have so far been most extensively explored in the context of a betting
market application known as Augur, which itself functions by executing smart contracts
among bettors [/one.lf/three.lf/zero.lf]./three.lf/two.lf
Smart contracts may also be used as building blocks, of a sort, for designing higher-level
applications. Augur, just mentioned, is one example. Other examples include proposed
applications that would use smart contracts to facilitate the rental of cloud computing
resources or storage space. In fact, Ethereum’s smart contract system is /fl.ligaexible enough to
build any possible decentralized application./three.lf/three.lf
/three.lf/two.lfAs a very simple example of how a consensus protocol like this could work, consider again the case of two
users who want to bet about the high temperature in their city. They could create a smart contract that depends
on the input of several other parties who do not know each other, such that the contract will pay whichever of
these inputs does not diverge from the median input by more than a degree. If these parties cannot collude, then
they will be incentivized to converge on the truth, since they should expect their self-interested counterparts
to converge on it too. A more sophisticated version of this protocol, for repeated bets, might track “reputa-
tion points” for users who input information, such that users with higher reputations receive more weight in
disagreements and earn higher premiums.
/three.lf/three.lfIn technical terms, Ethereum provides a "Turing-complete" language for writing applications.
/three.lf/five.lf
Unfortunately, the same limitations faced by decentralized applications discussed in sec-
tion /two.lf./six.lf./two.lf still apply. All established permissionless blockchains, including Ethereum, are
too ine/f\_f\_i.ligacient to run anything beyond fairly simple applications. Again, even something
as complex as an application that checks who has won a game of chess is pushing up against
Ethereum’s current limitations.
While researchers are currently investigating a number of ways to “scale” blockchains to
accommodate much greater numbers of users and much more complex applications, it is
not yet clear how e/f\_f.ligaective any such techniques will be (see section /four.lf./two.lf).
/two.lf./one.lf/one.lf Homomorphic encryption
Homomorphic encryption is a form of encryption that allows computations to be run on en-
crypted data, such that the outputs of the computations are encrypted as well [/one.lf/seven.lf/one.lf].
For instance, we say that an encryption scheme is “homomorphic under addition” if we
can encrypt any two numbers, perform a certain operation on them, and then decrypt the
result to return their sum. E/f\_f\_i.ligacient schemes that are homomorphic under only addition
or only multiplication have been known for a number of years./three.lf/four.lf
A scheme is known as fully homomorphic if it allows any computable function to be com-
puted on encrypted data. The /fi.ligarst fully homomorphic scheme was invented in /two.lf/zero.lf/zero.lf/nine.lf, by
Craig Gentry [/seven.lf/two.lf]. Since this time, a number of superior alternatives have also been pro-
posed.
The basic appeal of fully homomorphic encryption is that it makes it possible to create
applications in which service providers do not require access to clients’ unencrypted data.
Possible examples include cloud computing services that do not need to know the data
they are being asked to compute on, online medical services that /fl.ligaag health concerns on
the basis of individuals’ DNA without needing to know their genetic data, and targeted ad-
vertising services that do not need to know the interests that users have indicated through
their browsing behavior.
However, fully homomorphic encryption has not yet found signi/fi.ligacant use, as all known
schemes are highly ine/f\_f\_i.ligacient. The most e/f\_f\_i.ligacient schemes discovered so far still result in
many-orders-of-magnitude blowups in the size of the encrypted data as it is operated on,
and in the time the operations take to complete. For an example, in /two.lf/zero.lf/one.lf/four.lf, it was the case
that even a well-optimized implementation running on a moderately powerful computer
might be incapable of performing more than /five.lf/zero.lf multiplications per second (with addition
being much less costly) [/eight.lf]. This is actually a vast improvement over Gentry’s original
scheme, but still enormously slow. To a very rough approximation, fully homomorphically
encrypted data can be regarded as about a billion times less e/f\_f\_i.ligacient to compute on than
unencrypted data.
/three.lf/four.lfToday, the most widely applicable homomorphic encryption scheme is likely the Paillier encryption scheme ,
which is homomorphic under addition while also allowing for multiplication between encrypted inputs and
unencrypted ones. This is su/f\_f\_i.ligacient to compute any linear function of encrypted data.
/three.lf/six.lf
Some help is provided by somewhat homomorphic encryption schemes, developed concur-
rently, which o/f\_f.ligaer signi/fi.ligacant (but not decisive) speedups at the cost of allowing for only
a /fi.liganite number of multiplications. Over time, further progress in discovering e/f\_f\_i.ligacient
algorithms and in developing more powerful computers could make fully or somewhat ho-
momorphic encryption practical in a wide range of cases. For the moment, however, their
applications remain relatively narrow [/one.lf/one.lf/seven.lf].
In the following two sections, we consider an additional two technologies that allow com-
putations to be run on private data. These are functional encryption andsecure multiparty
computation .
/two.lf./one.lf/two.lf Functional encryption
Functional encryption is a form of encryption that allows particular functions of encrypted
data to be computed—such that, in contrast with homomorphic encryption, the output is
not encrypted [/two.lf/seven.lf].
For example, using functional encryption, a hospital could encrypt its patients’ medical
records in a way that allows di/f\_f.ligaerent categories of hospital workers, holding di/f\_f.ligaerent keys,
to compute only the information they need. A user of a cloud storage service could also
encrypt their /fi.ligales in a way that allows the service, or government investigators, to compute
only whether the /fi.ligales contain certain restricted material (like copyrighted media).
In general, a functional encryption system works in the following way:
•There exists a setup algorithm that can produce an almost certainly unique key pair,
consisting of a public key and a master private key . As in a regular public-key en-
cryption system, the public key, along with an encryption algorithm , can be used to
encrypt data.
•There also exists a key-generating algorithm that can, given a master private key and
a function, f, produce a special private key ,kf.
•Finally, there exists a decryption algorithm that can, given kfand a piece of data en-
crypted using the master private key, produce the function f(x).
•In a simple case, it is possible to encrypt one’s data using a master private key, then
grant others the ability to ascertain certain information from the data by distribut-
ing special private keys.
The concept of functional encryption is quite new, /fi.ligarst appearing in academic papers in
/two.lf/zero.lf/one.lf/zero.lf [/one.lf/two.lf/four.lf]. Researchers have since developed a number of general functional encryption
systems—meaning, systems whose key-generating algorithms can be used to produce a spe-
cial key for any desired function [/seven.lf/nine.lf, /seven.lf/eight.lf].
Similar to homomorphic encryption, functional encryption can make it easier to provide
privacy-preserving services. In the two examples given above, functional encryption allows
the hospital workers and the government investigators to gain just exactly the information
that is necessary to do their jobs.
/three.lf/seven.lf
In addition, while only a small amount of research has addressed practical implementations
of functional encryption, it can, for many functions, be much more e/f\_f\_i.ligacient than fully
homomorphic encryption [/one.lf/five.lf/zero.lf]. Nevertheless, applications of functional encryption have
been little explored.
/two.lf./one.lf/three.lf Secure multiparty computation and secret sharing
Finally, secure multiparty computation (MPC ) refers to techniques that allow users to run
computations with inputs from multiple parties, while allowing these parties to keep their
own inputs secret [/one.lf/five.lf/one.lf].
As a popular illustration, consider the service provided by dating applications like Tinder,
in which two people will receive a noti/fi.ligacation if and only if they both express interest in
the other. We can think of these applications as computing a function f(X,Y) , where Xand
Yrepresent the users’ inputs and frepresents whether or not both inputs are expressions of
interest. More importantly, these applications compute f(X,Y) for the two parties without
requiring them to share their inputs with one another. Since “no match” is compatible
with either one or two inputs of “not interested,” a user who inputs “not interested” gains
no information at all.
These applications solve the “dating problem” by acting as a trusted third party: they col-
lect both parties’ inputs and then promise to compute the function correctly and to not
share their inputs with anyone else. We might ask, though, whether it is possible to achieve
the same end without any trusted third party at all.
In fact, as Andrew Yao proved in a classic /one.lf/nine.lf/eight.lf/two.lf paper, MPC protocols can be used to
solve the dating problem without trusted third parties [/one.lf/eight.lf/five.lf]./three.lf/five.lfBy engaging in a fairly
complex sequence of interactions and individual computations, the two potential daters
can together compute f(X,Y) while maintaining their individual privacy. Since this time,
cryptographers have also learned that MPC protocols can be designed to compute any
joint function of private inputs, for any number of parties. In just the past decade, there
has been substantial progress in developing MPC schemes that are practical to implement,
with e/f\_f\_i.ligaciency increasing by several orders of magnitude [/seven.lf/four.lf].
The /fi.ligarst economically signi/fi.ligacant application came in /two.lf/zero.lf/zero.lf/eight.lf, when MPC was used to carry
out a secure sugar beet auction in Denmark with over one thousand bidders [/two.lf/six.lf]. In this
case, the various parties determined the winning bid for each item without otherwise shar-
ing their bids with one another. Without MPC, they would have needed to share their bids
either with one another, or with a third party who was trusted to report the proper out-
come.
One frequently discussed use case for MPC is in secure voting systems, which would allow
voters to jointly determine the outcomes of elections without sharing their votes with one
another or trusting any third party to tabulate them [/five.lf/three.lf]. Another use case is training ma-
chine learning systems across multiple privately held datasets, such as individual medical
/three.lf/five.lfTechnically, Yao showed this for a more general problem he called the “millionaires’ problem.”
/three.lf/eight.lf
records or classi/fi.ligaed information held by di/f\_f.ligaerent government agencies [/one.lf/zero.lf/eight.lf].
In addition, we can understand the use of homomorphic encryption to provide privacy-
preserving services (see section /two.lf./one.lf/one.lf) through the lens of MPC [/four.lf/seven.lf]. Speci/fi.ligacally, client-
server applications (see section /two.lf./six.lf./one.lf) in which the client homomorphically encrypts the
data they send to the server can be interpreted as implementing a particular variety of
MPC, in which the client’s input is the data to be encrypted, the server’s input is the al-
gorithm to be applied to that data, and only the client receives the computation’s output.
While processing data in this way is associated with enormous computational overhead, as
stated above, there exist other MPC protocols that accomplish the same end much more ef-
/fi.ligaciently. This reduction comes at the cost of requiring extensive communication between
the server and client and, in general, requiring the client to be a much more active partic-
ipant. Nevertheless, these more communication-heavy MPC protocols are comparatively
practical.
Another way to use more e/f\_f\_i.ligacient MPC protocols to o/f\_f.ligaer privacy-preserving services, in
this case without placing such a large burden on the client, involves a cryptographic tech-
nique known as secret sharing [/one.lf/four.lf/eight.lf]. In secret sharing, a private piece of data, or secret , is
divided into a number of shares . These shares individually provide no information about
the secret, but if su/f\_f\_i.ligaciently many of the shares are combined, then the secret can be re-
trieved.
Consider the following protocol:
•Alice has some data, X, and she would like some function of it, f(X), to be computed.
To make the case concrete, we might imagine that Xis personal medical data and
f(X)is a list of health risks suggested by the data.
•Alice splits her data into a number of shares, using secret sharing, and distributes
the shares among an equal number of other parties.
•Now, so long as each party keeps its own share private, the problem of computing
f(X)is transformed into an MPC problem with the shares as inputs.
•Running the MPC protocol until just before its end results in each party holding,
in e/f\_f.ligaect, a share of f(X). At this point, they send their output shares to Alice alone,
and she recombines them to learn f(X). She has received a service from these parties
without sacri/fi.ligacing her privacy.
In general, the use of secret-sharing protocols makes it possible to separate the parties that
provide a computation’s data inputs, the parties that receive its outputs, and the parties
that perform the bulk of the computational work. We can divide the relevant parties up
into the input parties ,computing parties , and results parties (see Figure /five.lf) [/one.lf/six.lf/zero.lf]. The input
parties divide shares of their data among the computing parties. The computing parties
compute shares of a joint function of this data. The results parties receive these shares and
join them together to learn the /fi.liganal output. In a classic MPC protocol, these three sets
of parties would all be the same. In the above description, though, Alice is the only input
party and the only results party, and she is not a computing party.
/three.lf/nine.lf
Figure /five.lf: In this MPC protocol, the input parties use secret sharing to distribute shares of
their private data, XandY, among the computing parties. The computing parties compute
shares of a function of this data, f(X,Y) , and then send these shares to a results party that
combines them to learn f(X,Y) . In general, a single party might play multiple roles. In classic
MPC protocols, the input parties, computing parties, and results parties are all the same.
The most obvious security challenge with secret-sharing MPC protocols is the need to
ensure that the computing parties do not collude to combine their shares, thereby learning
the relevant secrets. Another worry is that computing parties might not carry out their
portions of the computations correctly.
While stricter security standards imply stronger requirements, there exist protocols in
which even a single honest party is su/f\_f\_i.ligacient to ensure privacy of the relevant data. Fur-
thermore, conditional on the assumption that the computing parties have access to a trust-
worthy public log, there exist protocols that also allow even uninvolved parties to verify
that the computation was performed correctly [/one.lf/four.lf].
It is not unreasonable to think that these requirements—a trustworthy public log and a
single honest party—can often be met. Blockchains, or even just simple tamper-evident
logs, are a good way of meeting the /fi.ligarst requirement. Economic incentives may provide
an ideal way of meeting the second. One solution might be to rely on companies whose
business models depend on their reputations as reliable computing parties for MPC proto-
cols. Another solution is being explored by an MIT-based project known as Enigma [/one.lf/eight.lf/seven.lf].
Enigma is a decentralized application (see section /two.lf./six.lf./one.lf) meant to implement a market
for MPC computations. Parties contract others to serve as computing parties, and these
parties lose substantial cryptocurrency deposits if they are found to engage in malicious
behaviors.
The use of MPC is still associated with substantial overheads. For example, at the time
/four.lf/zero.lf
of writing, the most e/f\_f\_i.ligacient MPC protocols increase the time required to train a deep
learning system by about a factor of one thousand [/one.lf/seven.lf/seven.lf]. However, these overheads are
far smaller than the overheads associated with fully homomorphic encryption. They are
already quite manageable for short computations. Further innovations may decrease these
overheads even further./three.lf/six.lf,/three.lf/seven.lf
/three.lf/six.lfAt the time of writing, OpenMined is perhaps the most active project attempting to reduce barriers to
the widespread adoption of MPC [/one.lf/two.lf/six.lf]. Their primary focus is on developing software libraries that make it
easier for data scientists and machine learning engineers to implement e/f\_f\_i.ligacient MPC protocols, alongside other
privacy techniques. They also publish educational materials and advocate for the adoption of MPC and related
techniques.
/three.lf/seven.lfOne unifying perspective on zero-knowledge proofs, homomorphic encryption, functional encryption, and
secure multiparty computation is that they support what might be called structured transparency : precise controls
on who can know what, when they can know it, and what they can do with this knowledge (see section /three.lf./one.lf./two.lf) [/one.lf/six.lf/seven.lf].
For instance, the computing parties for a computation performed using MPC, unlike the computing parties for
a typical computation, do not need to know what its inputs or outputs are. The party reading a zero-knowledge
proof, unlike the reader of a typical proof, does not need to know anything besides the simple fact that the proof
is valid. The social value of structured transparency techniques is that, in many cases, they can enable desired
uses of information without also opening the door so widely to undesired misuse.
/four.lf/one.lf
/three.lf Speculative consequences
In this section, I gather and discuss a number of possible consequences of the developments
described above.
Since the full range of possibilities is of course very broad, I have limited myself to conse-
quences that I believe would have large-scale political signi/fi.ligacance. For example, although
a number of banks have investigated the possibility that consortium blockchains will allow
them to reconcile their records more e/f\_f\_i.ligaciently, it is not su/f\_f\_i.ligaciently clear to me that the
e/f\_f.ligaects of these developments would seep far outside the /fi.liganancial industry.
I will be considering the following seven possibilities:
/one.lf. Information channels used to conduct surveillance could “go dark”
/two.lf. Privacy-preserving surveillance could become feasible
/three.lf. Non-intrusive agreement veri/fi.ligacation could become feasible
/four.lf. It could become easier to combat forgery
/five.lf. The roles of banks, technology companies, voting authorities, and other traditional
institutions could shrink
/six.lf. It could become feasible to solve collective action problems that existing institutions
cannot
/seven.lf. A new variety of institutions, known as “decentralized autonomous organizations,”
could emerge
There are of course reasons, sometimes quite strong reasons, to be skeptical of each of
these possibilities. I discuss some reasons for skepticism within this section, but section
/four.lf, “Limitations and skeptical views,” describes several in signi/fi.ligacantly greater detail. This
section of the report is less focused on the question “What is likely to happen?” than it
is on the questions “What are the most interesting predictions that other researchers or
engineers have made?” and “What predictions would be truly consequential if they came
true?”
In addition, it should be noted that a period of several decades can often separate the
initial development of a technology and its eventual re/fi.liganement and adoption [/eight.lf/five.lf]. Even
predictions that are plausible in the long run may still be implausible, say, within the
next ten years. In fact, a number of these possibilities explicitly require very signi/fi.ligacant
technological progress.
/three.lf./one.lf Consequences from technologies other than blockchain
/three.lf./one.lf./one.lf Information channels used to conduct surveillance could “go dark”
Three trends could conceivably make surveillance signi/fi.ligacantly more di/f\_f\_i.ligacult: /fi.ligarst, the
growing use of end-to-end public-key encryption; second, the emergence of digital cur-
rency systems that apply zk-SNARKs and other techniques meant to obscure economic
transactions; and, third, the potential for methods of computing on con/fi.ligadential data to
alter the economics of private data collection.
/four.lf/two.lf
As discussed in section /two.lf./one.lf, it has only recently become common for major providers of
messaging services to o/f\_f.ligaer “end-to-end encryption” for all messages that users send. “End-
to-end encryption” refers to a process of encryption and decryption that occurs solely on
the sender’s and receiver’s devices, meaning, in practice, that the service provider cannot
access the messages even if they would like to [/five.lf/nine.lf]. This, further, prevents government
agencies from gaining access via the service provider./three.lf/eight.lfJust over the course of /two.lf/zero.lf/one.lf/six.lf, the
number of end-to-end encryption users likely increased by more than a billion [/one.lf/two.lf]. This
change is due to a number of major applications, most notably WhatsApp, beginning to
o/f\_f.ligaer the service by default. In addition, there is the less widely recognized prospect of
increasingly practical end-to-end encrypted messaging systems that obscure not just the
content of messages but also the associated “metadata”—particularly, data about who is
messaging whom [/five.lf/nine.lf, /one.lf/seven.lf/two.lf]. A number of prominent o/f\_f\_i.ligacials, such as former FBI director
James Comey, have responded to the growing use of end-to-end encryption by sounding an
alarm that information channels they rely on are “going dark” [/five.lf/one.lf, /seven.lf/zero.lf]. While the Chinese
government has moved to crack down on the use of this technology, civil liberty concerns
provide signi/fi.ligacant barriers to regulation in many other countries [/three.lf/zero.lf]./three.lf/nine.lf
The development and adoption of privacy-preserving cryptocurrencies may lead a further
information channel to “go dark.” While it is sometimes perceived that today’s widely
used cryptocurrencies already o/f\_f.ligaer signi/fi.ligacant privacy, this perception is mostly mistaken
[/one.lf/three.lf/four.lf, /one.lf/one.lf/nine.lf]. As discussed in section /two.lf./seven.lf, for most cryptocurrencies the full details of every
transaction are recorded by the relevant blockchain for everyone to see, and it is in prac-
tice fairly easy to tie users’ pseudonyms to their real-world identities. If cryptocurrencies
do ultimately make surveillance much more di/f\_f\_i.ligacult, then, it may be the result of cryp-
tocurrencies that apply zk-SNARKs (or other varieties of non-interactive zero-knowledge
proofs). At least one new cryptocurrency, Zcash, claims to o/f\_f.ligaer users the ability to make
transactions whose contents and participants are obscured from other users. Zcash is not
yet widely used, but the developers have been gradually expanding zk-SNARK support
on the Ethereum blockchain (see section /two.lf./one.lf/zero.lf). Despite some lingering security, e/f\_f\_i.ligaciency,
and user demand concerns, in the long run it seems plausible that cryptocurrency transac-
tions will become signi/fi.ligacantly less transparent. In addition, even if zk-SNARKs or other
forms of zero-knowledge proofs do not become widely used, a handful of other methods of
obscuring transactions, including “mixing services,” “ring signatures,” and “state/payment
channels,” could achieve similar e/f\_f.ligaects.
Finally, methods of running computations on encrypted data might lead further informa-
tion channels to go dark. “Don’t Panic,” a /two.lf/zero.lf/one.lf/six.lf report associated with Harvard’s Berkman
Center for Internet and Privacy, argues that the “going dark” problem is overstated due,
in large part, to private companies’ economic incentives to collect user data [/seven.lf/zero.lf]. While
this point is likely robust in the short run, and indeed the medium run, it may not be in
/three.lf/eight.lfAlthough, as mentioned above, even the use of perfectly implemented end-to-end encryption does not guar-
antee perfect security, for instance, if the user’s personal device is insecure or if they are tricked or coerced into
revealing their password. In addition, an agency might still convince service providers to weaken protections on
some users through software updates.
/three.lf/nine.lfThe European parliament has even recently considered a proposal, motivated by civil liberty concerns, to
prevent member states from banning the use of end-to-end encryption [/seven.lf/five.lf].
/four.lf/three.lf
the long run. As discussed in sections /two.lf./one.lf/one.lf–/two.lf./one.lf/three.lf, technologies such as secure multiparty
computation, functional encryption, and homomorphic encryption can reduce economic
incentives to collect unencrypted user data. Just as end-to-end encryption makes it possi-
ble for a service to send messages for a user without gaining access to their contents, these
technologies make it possible to send users targeted ads without gaining access to their in-
terests, to train machine learning algorithms on users’ activity logs without gaining access
to these logs, and so on. In addition, there are a number of less powerful, but already practi-
cal techniques for learning from user data in a privacy-preserving manner [/two.lf]. For instance,
di/f\_f.ligaerential privacy techniques work by making random alterations to datasets in order to
prevent the individuals included in the datasets from being identi/fi.ligaed. In /two.lf/zero.lf/one.lf/six.lf, Apple
began to apply these techniques to data associated with the use of its devices [/one.lf/six.lf/one.lf].
On the other hand, it is not impossible to imagine a future in which cryptographic devel-
opments could support the expansion of surveillance in certain ways. For example, as will
be discussed in the next section, methods of computing on con/fi.ligadential data could make
it easier to gather security-relevant information about individuals without also gaining
access to irrelevant private information. This capability could make it easier for govern-
ment agencies to engage in robust surveillance without running up against privacy con-
cerns.
In addition, it is very plausible that other technological developments, mostly unrelated
to cryptography, will ultimately play a larger role in increasing the ease of surveillance.
Video surveillance augmented by arti/fi.ligacial intelligence, for example, may become much
more pervasive. Some authors have also raised the possibility that, in the coming decades,
small and di/f\_f\_i.ligacult-to-detect drones could become highly e/f\_f.ligaective tools for surveillance
[/one.lf/eight.lf/one.lf]. More prosaically, the authors of the Berkman Center report highlight the growing
number of sensor-bearing devices that make up the “internet of things” as one long-run
trend that is making surveillance easier. Ultimately, when it comes to the future feasibility
of surveillance, new developments in cryptography might be of fairly secondary impor-
tance.
/three.lf./one.lf./two.lf Privacy-preserving surveillance could become feasible
In discussions of surveillance, the supposed trade-o/f\_f.liga between privacy and security is fre-
quently discussed. While this “trade-o/f\_f.liga” narrative is heavily simpli/fi.ligaed in a number of
ways—excluding, among other points, the fact that privacy can itself provide security
against exploitation—it does still capture something of the truth [/one.lf/eight.lf/one.lf, /one.lf/five.lf/two.lf].
A trade-o/f\_f.liga will exist to whatever extent the ability to access security-relevant information
also entails the ability to access information that would ideally remain private. For exam-
ple, for a police o/f\_f\_i.ligacer manually searching bags, learning whether someone is carrying a
weapon also requires learning everything else they are carrying. The choice is either to
forgo security-relevant information (whether there is a weapon in the bag) or to obtain
extraneous private information (what else is in the bag).
Fortunately, there is no fundamental reason why granting a party the ability to learn
security-relevant information must entail granting them the ability to learn anything else.
/four.lf/four.lf
Bomb-sni/f\_f\_i.ligang dogs, which report only whether there are explosives within a given bag, can
be seen as an example of a technology that minimizes the privacy-security trade-o/f\_f.liga in the
case just described (at least, in the idealized case that the dogs have perfect accuracy) [/three.lf/one.lf].
Technological progress may make it become possible to minimize the trade-o/f\_f.liga in a wider
and wider variety of domains. Or, to re-express this point in the terminology of one recent
paper, it may become increasingly possible to achieve structured transparency [/one.lf/six.lf/seven.lf].
For the surveillance policy, the basic principles are these:
Surveillance tasks can be automated: If progress in arti/fi.ligacial intelligence con-
tinues, then it will become possible to automate an increasingly large portion
of the tasks currently performed by human analysts (as well as tasks that hu-
man analysts cannot currently perform). For example, AI systems are likely to
become more capable of identifying faces in videos, noticing suspicious pat-
terns of transactions, and judging from private messages whether someone is
engaged in illegal activity.
If a surveillance task can be automated, then it can be completed without
access to private data: In any case where an AI system is extracting security-
relevant information from private data, it is, in principle, possible to design
the system in a way that does not require the party running it to collect the
data in unencrypted form. The relevant technologies, which enable comput-
ing on con/fi.ligadential data, include secure multiparty computation, functional
encryption, and homomorphic encryption (see sections /two.lf./one.lf/one.lf–/two.lf./one.lf/three.lf)./four.lf/zero.lf
Generally, work on the applications of cryptographic technologies to privacy-preserving
surveillance has received fairly little attention [/six.lf/six.lf, /one.lf/four.lf/five.lf, /two.lf/two.lf, /six.lf/nine.lf]. However, in recent years
there have been some useful proofs of concept. The most noteworthy case is probably the
development of an MPC-based system to detect cases of value-added tax fraud in Estonia:
although the system was not ultimately adopted, it was designed to identify discrepancies
between declared sales and purchases without violating the con/fi.ligadentiality of individual
companies’ /fi.liganancial records [/two.lf/five.lf].
There have also been proposed protocols for privacy-preserving “set intersection” searches,
which identify individuals who reappear across several datasets of interest [/one.lf/four.lf/six.lf]. For exam-
ple, set-intersection searches are sometimes used to identify criminals from multiple sets
of cell tower records associated with locations where they are known to have committed
crimes. A trivial form of secure multiparty computation over the datasets could prevent
the investigators from needing to access the full datasets in cases like these. Similarly,
widely used “contact-chaining” techniques, which generate lists of suspicious individuals
on the basis of social network analysis, could easily be implemented without extraneous
/four.lf/zero.lfAn intermediate privacy solution, which agencies such as the National Security Agency already employ to
varying degrees, is to collect and store unencrypted data, but limit the access of individual analysts. An analyst,
for example, may be allowed to make only a limited set of queries to the database and only view the portion
of records that are classi/fi.ligaed as matching these queries. However, systems like this provide weaker assurances of
privacy, in that they depend on the continued self-restraint of the agencies holding the data. The act of collecting
the data is also subject, in many cases, to signi/fi.ligacant legal constraints.
/four.lf/five.lf
data collection.
To illustrate the potential breadth of long-run possibilities, I will now describe a gen-
eral protocol for privacy-preserving mass surveillance with secure multiparty computation.
This protocol is inspired by Andrew Trask, a machine learning researcher, who recently
described a similar protocol that employs homomorphic encryption instead [/one.lf/six.lf/six.lf]. The
protocol would infeasible to implement today, but can interpreted as a kind of “limiting
case” of what might be possible in the future.
•Technology companies and service providers each maintain their users’ data inde-
pendently. No government agency collects this data.
•A number of these companies maintain subsidized data centers, which are designed
to engage in secure multiparty computations with a certain government agency.
•The agency develops a classi/fi.ligaer system intended to identify criminal activity on
the basis of personal data. An example of a simple classi/fi.ligaer would be one that just
performs set-intersection searches on cell records, identifying individuals who were
present at multiple linked crime scenes. A more sophisticated classi/fi.ligaer might use a
variety of more sensitive data, including the contents of private messages, to identify
individuals who appear to be involved in particular criminal activities. The classi/fi.ligaer
is tested to ensure that it does not exceed a mandated maximum false positive rate./four.lf/one.lf
•This procedure is overseen by an independent auditing body. The body con/fi.ligarms
that the classi/fi.ligaer has the properties claimed. Once the classi/fi.ligaer is put into use, the
auditing body will also be tasked with con/fi.ligarming that its false positive rate remains
below the maximum allowed value.
•Now, the agency engages in a secure multiparty computation with the relevant com-
panies. The inputs to the computation are each company’s private data and the pa-
rameters of the agency’s classi/fi.ligaer. (Data from other sources might also be included
through secret sharing.) The output, which is received only by the agency, is a list
of individuals that the classi/fi.ligaer deems su/f\_f\_i.ligaciently suspicious. The agency may ul-
timately request further data on these individuals from the companies, subject to
judicial approval.
•Di/f\_f.ligaerent classi/fi.ligaers could be deployed for di/f\_f.ligaerent crimes. The explicitly coded
threshold for reasonable suspicion or probable cause could also vary with the severity
of the crime and could be decided through public debate./four.lf/two.lf,/four.lf/three.lf
/four.lf/one.lfThe classi/fi.ligaers could be trained and tested by using datasets that are known to include examples of both
criminal and law-abiding behavior.
/four.lf/two.lfHistorically, at least within the United States, it has been held that the standards for probable cause resist
quanti/fi.ligacation. However, with the rise of sni/f\_f\_i.ligang dogs, partial /fi.ligangerprint matches, facial recognition technol-
ogy, and other “mechanistic” methods of establishing probable cause, it has become relatively common to take
statistical evidence into account, at least in an ad hoc manner [/seven.lf/seven.lf]. For example, if probable cause is established
solely on the basis of a match made by facial recognition software, then the evidence is essentially nothing but
statistical; it consists of the fact that software is making a certain classi/fi.ligacation and that the software is right a
su/f\_f\_i.ligaciently large portion of the time. Some legal scholars argue that, in mechanistic cases, the most natural way
to de/fi.ligane probable cause is simply to de/fi.ligane a necessary accuracy rate.
/four.lf/three.lfExpanding the role of statistical evidence in establishing reasonable suspicion and probable cause, currently
/four.lf/six.lf
•Finally, at least within the United States, the legal justi/fi.ligacation for using such a
classi/fi.ligaer could be similar to the justi/fi.ligacation for using sni/f\_f\_i.ligang dogs. In relevant
Supreme Court cases, it has traditionally been held that, insofar as the dog is only
capable of reporting unlawful activity, with su/f\_f\_i.ligaciently high accuracy, and insofar
as the dog is not trespassing on its target’s property, then its use does not constitute
a “search” [/three.lf/one.lf, /five.lf/zero.lf].
It may be instructive to examine this illustrative protocol further, in order to highlight sev-
eral important barriers to its implementation (or the implementation of similar privacy-
preserving surveillance protocols). First, for most instances of criminal activity, it is not
yet possible to develop classi/fi.ligaers that are su/f\_f\_i.ligaciently accurate. This is particularly true
for crimes with very small rates of occurrence, such as terrorism. The viability of the pro-
tocol, outside of narrow contexts, then requires extremely signi/fi.ligacant progress in arti/fi.ligacial
intelligence to raise the achievable accuracy level. Taking the long view, though, it is worth
noting that most experts in the /fi.ligaeld of arti/fi.ligacial intelligence expect computer systems to
become capable of completing all tasks that humans can within a century [/eight.lf/two.lf]. The wait
for AI systems to be able to complete many individual classi/fi.ligacation tasks may be substan-
tially shorter. In addition, a number of tasks, such as set-intersection searches, are either
already automated or trivial for existing systems.
Second, as already discussed, secure multiparty computation is very expensive. The com-
putational overhead and the need for interaction between the multiple parties could be ex-
pected, with current techniques, to increase the total cost of running any classi/fi.ligaer by mul-
tiple orders of magnitude. This increase is not necessarily unbearable, especially given that
available computing power and bandwidth have historically increased by about a factor of
a hundred every decade [/one.lf/zero.lf/nine.lf, /one.lf/two.lf/one.lf]. Still, every additional dollar of cost should be assumed
to decrease the technical and political viability of a privacy-preserving scheme.
Third, in this scheme, there is still a need for the companies and the public to trust the
auditing body to ensure the agency’s honesty. Fortunately, it may be possible to loosen this
constraint. As discussed in section /two.lf./eight.lf, zk-SNARKs can be used to publicly demonstrate
that a government agency is in fact applying an algorithm that has received an auditing
body’s approval, without revealing the details of the algorithm to the public [/one.lf/zero.lf/three.lf]. In the-
ory, it might even be possible to use zk-SNARKs to publicly demonstrate that the classi/fi.ligaer
achieves the desired accuracy rate without requiring trust to be placed in any auditing body
at all.
Fourth, this version of the scheme requires the relevant service providers to have access to
their users’ data. It presumes that they do not o/f\_f.ligaer end-to-end encryption of messages, or
homomorphic processing of data. One more di/f\_f\_i.ligacult alternative would be to require indi-
quite minor, might also be seen as its own end [/one.lf/one.lf/five.lf]. For example, a judge determining whether a police o/f\_f\_i.ligacer had
probable cause to conduct a search, on the basis of their claim that a certain driver appeared suspicious, would
not typically take into account the o/f\_f\_i.ligacer’s track record. Intuitively, though, it is of great relevance whether the
o/f\_f\_i.ligacer’s judgements about suspicious drivers are correct /one.lf/zero.lf/zero.lf% of the time or /zero.lf% of the time. An increase in the
use of statistical evidence, which would be quite abundant for any classi/fi.ligaer applied to large quantities of data,
could enable more e/f\_f.ligaective oversight, more precise discussions of standards, and more uniformly high-quality
decisions.
/four.lf/seven.lf
viduals to share their data with a number of independent entities, through secret sharing,
for the sole purpose of allowing these entities to use it for surveillance purposes. Public
surveillance footage and other data not directly associated with technology companies and
service providers could also be incorporated in this way.
Finally, even if all of these problems were resolved, there would still remain all of the legal,
political, and social challenges that would surely be associated with radically revising the
nature of a country’s surveillance policies and infrastructure. There would also be the
unavoidable fact that privacy-preserving surveillance can aid the enforcement of unjust
laws in exactly the same way that it aids the enforcement of just laws.
In short, the feasibility of privacy-preserving mass surveillance would require large tech-
nical advances and signi/fi.ligacantly more thought than has been devoted to it so far. There
may be reasons to be bullish about privacy-preserving surveillance in the long run, though.
The intersection between emerging cryptographic technologies and surveillance is still a
little-examined research area, and if fundamental barriers to privacy-preserving surveil-
lance exist, then they are not obvious.
I should also emphasize that broad privacy-preserving surveillance protocols, if they be-
come feasible, should not be assumed to be socially beneﬁcial . Again, if some law is unjust,
then removing privacy concerns as a barrier to its enforcement would be harmful. There
are also sensible reasons to be wary of any large expansions of surveillance powers, even
if the laws in question are just and even if privacy-preserving techniques will be used.
Nonetheless, if highly privacy-preserving surveillance ever becomes feasible, then it is easy
to imagine surveillance powers eventually expanding in many countries.
/three.lf./one.lf./three.lf Non-intrusive agreement veri/fi.ligacation could become feasible
Just as methods of computing on con/fi.ligadential data might enable less invasive government
surveillance, in the long run they could also enable less intrusive methods of verifying
agreements.
The classic problem here is that nearly any agreement—such as an arms control agreement
between countries—will require information to be collected to provide assurance of each
party’s compliance. However, the act of collecting this information can often be highly
intrusive and will generally result in the veri/fi.ligaer gaining access to information beyond the
mere fact of the other party’s compliance or non-compliance [/six.lf]. For example, agreements
concerning chemical materials often entail inspections of private companies, which put
these companies’ valuable “con/fi.ligadential business information” at risk [/one.lf/zero.lf/zero.lf]. Similarly, the
party verifying a disarmament agreement might take it as an opportunity to learn more
about the weapons system being destroyed [/five.lf/two.lf]. If the cost of intrusion is great enough,
then an otherwise mutually bene/fi.ligacial agreement might become politically infeasible [/one.lf/two.lf/five.lf].
Even in cases where the cost of intrusion is ultimately deemed to be acceptable, like the
JCPOA agreement concerning Iran’s nuclear program, this cost can be a source of di/f\_f\_i.ligaculty
in negotiations, and attempts to decrease it can also decrease assurance [/four.lf/two.lf].
As above, we can construct minimally intrusive tools for veri/fi.ligacation, if we assume there
/four.lf/eight.lf
will eventually be extremely signi/fi.ligacant advancements in arti/fi.ligacial intelligence and in the
e/f\_f\_i.ligaciency of computing on con/fi.ligadential data. Ultimately, international agreement moni-
toring is just another form of surveillance. The only di/f\_f.ligaerence is that the subject of the
surveillance is party to an international agreement.
Beyond the secure computation techniques discussed in the previous section, zero-knowledge
proofs may also have their own applications to veri/fi.ligacation. For any future agreements
concerning algorithms—such as algorithms applied in autonomous weapons systems, vot-
ing systems, or systems used to make decisions with relevance to human rights—zero-
knowledge proofs could be a tool for demonstrating that only algorithms with approved
features are being applied [/one.lf/zero.lf/three.lf].
In addition, as mentioned in section /two.lf./eight.lf, some applications of “physical zero-knowledge
proofs” to agreement veri/fi.ligacation are already beginning to be found. Most signi/fi.ligacantly,
recent papers have proposed a method of demonstrating that a country is disposing of a
genuine nuclear warhead without revealing its design details [/seven.lf/six.lf].
It is interesting to consider what new applications of zero-knowledge proofs and physical
zero-knowledge proofs might be discovered in the coming years. One important limi-
tation, of course, is that we should not expect them to be any more powerful than tra-
ditional methods of demonstrating claims. For example, zero-knowledge proofs of non-
existence —such as a proof that a certain prohibited material does not exist anywhere within
a country’s borders—should be taken as much more di/f\_f\_i.ligacult than zero-knowledge proofs
of existence.
/three.lf./one.lf./four.lf It could become easier to combat forgery
As discussed in section /two.lf./four.lf, trusted timestamping can be used to combat forgery in a num-
ber of domains.
Timestamps put an upper bound on when a piece of data was created, providing assurance
that, at the very least, it was not forged or tampered with after the fact. For example,
an organization that has a strict policy of timestamping important documents can reduce
a number of risks, from corrupt o/f\_f\_i.ligacials altering incriminating documents to external
actors presenting forgeries as authentic. In large part, such concerns motivate the interest
actors such as the Estonian and British governments have recently taken in timestamping
services.
In the future, timestamping may also play an increasingly large role in helping people
to distinguish between authentic photographs and videos and arti/fi.ligacially generated ones.
Progress in machine learning has recently made it possible to generate images that are
almost indistinguishable from ones recorded by cameras. Similarly, although at great ex-
pense and using rather di/f\_f.ligaerent techniques, Hollywood studios have recently gained the
ability to produce nearly photorealistic renderings of long-dead actors. Taking note of
these trends, some commentators have suggested that we may lose our ability to trust in
the authenticity of digital media, with signi/fi.ligacant negative implications for journalists, in-
telligence services, and other groups relying on photo or video evidence [/four.lf, /three.lf/two.lf, /one.lf/four.lf/three.lf].
/four.lf/nine.lf
While timestamps alone do not solve this problem, they can still help substantially. Con-
sider someone recording a video and timestamping batches of frames as they do. If they
include in the video a depiction of certain information they could not have possessed be-
fore a certain time—such as a newspaper held aloft or, better yet, a projection of incoming
Bitcoin transactions—then this also serves to put a lower bound on when, if the video were
a forgery, they could have begun the /fi.liganal stage of editing. If the gap between this lower
bound and the upper bound provided by the timestamp is small enough, then it can be
regarded as implausible that the video is a forgery.
While such techniques are fairly cumbersome, their feasibility suggests that it should re-
main possible to demonstrate the authenticity of at least the most important digital me-
dia./four.lf/four.lf
/three.lf./two.lf Consequences from blockchain-based technologies
/three.lf./two.lf./one.lf Background: Concepts in institutional economics
Before turning to the political consequences of blockchain, it will again be useful to lay
out some background concepts. In this section, I give a quick overview of certain concepts
from new institutional economics , which explore the nature and purpose of institutions from
an economic perspective.
It sometimes happens that parties would /fi.ligand it mutually bene/fi.ligacial to enter into a certain
agreement with each other, but in practice fail to do so. These cases constitute collective
action problems . A classic illustration of a collective action problem is the tragedy of the
commons [/eight.lf/seven.lf]. In this case, the members of a village all have access to the same grazing /fi.ligaeld.
To avoid depleting the grass, the villagers will need to limit their consumption. However,
for any given individual, the cost of limiting one’s own consumption is not o/f\_f.ligaset by the
slight decrease in the rate of depletion. It follows that if everyone is left to their own
devices, then the grass will be collectively depleted. Everyone would be made better o/f\_f.liga by
a village-wide agreement on limited consumption, but the strong individual incentives to
cheat might make such an agreement impractical.
Importantly, many of the world’s most salient problems are at least in part problems of
collective action. For example, the failure of the international community to properly
address global problems like climate change and pandemic risk can be considered highly
analogous to the tragedy of the commons [/one.lf/seven.lf/four.lf]. Mutually harmful wars and arms races are
another large-scale example. Some economists, like Bryan Caplan, have also characterized
political apathy and irrationality as a sort of collective action problem; everyone would be
better o/f\_f.liga if everyone else became more well-informed and epistemically rational, but the
individual bene/fi.ligats of doing so are extremely low [/four.lf/three.lf].
One way to explain the source of collective action problems is to apply the framework of
/four.lf/four.lfAnother proposed technique, in a somewhat di/f\_f.ligaerent vein, is the use of physically tamper-proof cameras
that digitally sign the images they record. The upside of this technique is that it is much easier for users to
implement, while the downside is that it requires trust to be placed in the camera manufacturers and in physical
methods for preventing tampering (which are relatively more ad hoc than cryptographic ones).
/five.lf/zero.lf
transaction costs [/one.lf/six.lf/two.lf]. The realization of each possible agreement is associated with a set
of costs, which can in turn be divided into search costs, bargaining costs, and commit-
ment costs. First, the search costs are associated with /fi.liganding parties to enter the agreement
with and learning whatever information would be necessary to identify the agreement as
mutually desirable. Second, the bargaining costs are associated with converging on the agree-
ment, given the available information, and perhaps formalizing it. Finally, the commitment
costs are associated with increasing the probability that the parties will comply with the
agreement and risking the possibility that they will not. These commitment costs might
include the costs of monitoring the relevant parties, engaging in a potential arbitration
process, or establishing credible threats, as well as the expected costs implied by possible
non-compliance. In addition, in keeping with the above discussion of veri/fi.ligacation (see sec-
tion /three.lf./one.lf./three.lf), there are often transaction costs associated with the need to share extraneous
sensitive information in order to share information that is relevant. These may be classed
as either search costs or commitment costs, depending on whether they precede or follow
the relevant agreements.
In the case of the tragedy of the commons, the work involved in gathering the villagers
together and discussing an agreement not to overgraze would constitute search and bar-
gaining costs. The work involved in keeping watch over the /fi.ligaeld, the work involved in
punishing violators, and the value of any grass lost to undetected overgrazing would be
examples of commitment costs.
If any party’s share of the transaction costs associated with an otherwise mutually desirable
agreement outweighs their share of its bene/fi.ligats, then, given that the party is rational, there
will be a collective action problem.
Social institutions are critical for resolving collective action problems. They can be de/fi.liganed,
rather abstractly, as stable patterns of behavior and expectation within a community. For
example, within a country, the common tendency to accept certain pieces of paper (e.g.,
U.S. dollars) in exchange for goods, and the common expectation that other people will
also accept these pieces of paper in exchange for goods, can be considered a social institu-
tion. Formal organizations like companies and governments can also be considered social
institutions. For example, some of the “patterns” that ultimately give shape to a police
department include: whose orders and which kinds of orders are treated as having force,
who is let into the building and given a uniform and who is not, how people on the street
respond to people in police uniforms, and so on.
The right social institutions can do a great deal to lower transaction costs [/one.lf/four.lf/four.lf]. Tra/f\_f\_i.ligac
rules save drivers from the cost of negotiating for the right of way, money saves businesses
from arranging complex trades, regulation and reputation saves buyers from the cost of in-
vestigating products, and e/f\_f.ligaective police departments save citizens from the myriad costs
of ensuring mutual non-aggression and respect for property. In addition, anthropologists
have found that cooperative norms tend to help small communities avoid most of the costs
entailed by literal tragedies of the commons [/one.lf/two.lf/eight.lf]./four.lf/five.lf
/four.lf/five.lfTypically, as communities grow in size, it becomes increasingly common to rely on institutions that are
formal, hierarchical, and centralized. However, more informal, socially /fl.ligaat, and decentralized institutions always
/five.lf/one.lf
One perspective on blockchain technology is that it supports the creation of new institu-
tions, which might may either compete with existing institutions (to solve the same sorts
of problems) or solve problems not solved by any existing institution.
/three.lf./two.lf./two.lf The roles of banks, technology companies, voting authorities, and other tradi-
tional institutions could shrink
Systems that rely on new cryptographic technologies could begin to supplant existing so-
cial institutions, if they can o/f\_f.ligaer more appealing versions of the services these institutions
provide.
First, one key feature of cryptocurrencies is that they allow users to make virtual payments
without relying on banks or credit card companies to act as intermediaries or on traditional
central banks to manage the underlying currency. If a signi/fi.ligacant number of people /fi.ligand
it appealing from an e/f\_f\_i.ligaciency, liberty, or privacy standpoint to avoid relying on these
institutions when possible, then their roles could shrink.
One early example of a decline in in/fl.ligauence, already discussed, is banks’ and credit com-
panies’ inability to prevent payments to WikiLeaks in /two.lf/zero.lf/one.lf/two.lf when all major companies
decided to refuse payments to the activist group. WikiLeaks supporters decided to simply
cut banks and credit card companies out of the process and donated tens of thousands of
dollars’ worth of bitcoin instead [/one.lf/one.lf/one.lf]. In the same vein, a sign of the potential decline of
central banks’ in/fl.ligauence is given by Venezuela, where a non-negligible number of citizens
have begun to store some of their wealth in cryptocurrencies, rather than the hyperin/fl.ligaated
national currency [/one.lf/two.lf/zero.lf]. The existence of cryptocurrencies like Zcash that use zk-SNARKs
to obscure how much currency each user owns may also pose problems for taxation, beyond
those already posed by the ambiguous status of cryptocurrencies as taxable assets.
The past few years have also seen growing interest in decentralized ﬁnance (orDeFi) appli-
cations [/six.lf/one.lf] that build on top of cryptocurrency systems. Examples include decentralized
cryptocurrency exchanges (which allow users to trade cryptocurrencies with one another)
and applications that support collateralized cryptocurrency loans (where the collateral is
another digital asset). These applications might reduce the roles of a number of additional
/fi.liganancial institutions.
Decentralized applications could also be used to reduce reliance on traditional technology
companies to provide services [/three.lf/eight.lf]. For example, there are a number of proposed or early-
stage decentralized applications to allow users to rent out storage space for encrypted /fi.ligales,
using smart contracts, as an alternative to services like Google Drive [/one.lf/seven.lf/six.lf]. If scalability
issues can be resolved (see section /four.lf./two.lf./one.lf), then, some writers have suggested, decentralized
services provided by companies like Uber might eventually become practical [/one.lf/three.lf/seven.lf].
Smart contracts, especially when used in conjunction with smart property, could conceiv-
ably allow people to reduce their reliance on courts and arbitrators when entering into
agreements. As the legal scholar Lawrence Lessig has noted, it is sometimes possible to
retain their importance.
/five.lf/two.lf
achieve a particular end through either legal code or computer code [/one.lf/zero.lf/five.lf]. In this sense,
smart contracts would appear to increase the space of possibilities for what can be achieved
through computer code. If people can more easily and frequently enter into agreements
with one another that they trust will be enforced, without needing to trust that courts
will enforce them, then this would seem to diminish the importance of traditional legal
systems [/one.lf/eight.lf/two.lf]./four.lf/six.lf
At the same time, as section /four.lf./two.lf./four.lf will discuss, smart contracts—or, at least, anything re-
sembling existing smart contracts—appear capable of /fi.ligalling only a sliver of the role cur-
rently /fi.ligalled by traditional contracts. Generally, the potential of decentralized services
might also be undermined by regulation (see section /four.lf./two.lf./two.lf), security issues with the con-
sensus protocols used in permissionless blockchains (see section /four.lf./two.lf./three.lf), or the possibility
that many existing institutions are “good enough” to remove most of the incentive to seek
alternatives (see section /four.lf./two.lf./five.lf).
In addition, there is some case to be made that emerging cryptographic technologies might
also help to bolster traditional centralized institutions. In particular, as discussed in sec-
tion /two.lf./eight.lf, applications of zk-SNARKs could help to increase the accountability of these in-
stitutions. The use of technologies for computing on con/fi.ligadential data might also alleviate
concerns about these institutions violating individuals’ privacy or exploiting their personal
information. The net e/f\_f.ligaect could be to increase the palatability of reliance on centralized
institutions and thereby decrease incentives to seek more decentralized or novel alterna-
tives.
/three.lf./two.lf./three.lf It could become possible to solve collection action problems that existing institu-
tions cannot
Permissionless blockchains and smart contracts may be able to lower some of the “com-
mitment costs” involved in solving collective action problems.
In certain cases, using a smart contract may remove the need to rely on a trusted third party,
who might be inclined to engage in opportunism, or to take other pains to incentivize
honesty. The parties engaged in a chess smart contract, to repeat an earlier example, do
not need to trust the loser to hand money over to the winner, an escrow service to handle
the transfer, or a court to extract compensation for dishonesty. Therefore, giving these
competitors the option of using a smart contract might decrease the overall cost of ensuring
that their agreement will be honored./four.lf/seven.lf
/four.lf/six.lfAs a related framing, contract enforcement mechanisms may be either public (for example, a formal legal
system) or private (for example, Ma/fi.ligaa enforcers or reputational harm) [/eight.lf/one.lf]. The use of smart contracts may
increase the relative prominence of private mechanisms.
/four.lf/seven.lfA secondary e/f\_f.ligaect of smart contracts, in some contexts, may also be to lower bargaining costs. It may
be particularly cheap to reuse sections of code from successful smart contracts, to write smart contracts that
depend on the outputs of other smart contracts, and to create open-ended smart contracts that any number of
parties can easily choose to engage with. As one example, an experimental smart contract-based venture capital
organization, described in section /three.lf./two.lf./four.lf, left room for an inde/fi.liganite number of users to join it. Although it quickly
failed due to a programming mistake, the computer code used to de/fi.ligane the relevant smart contract can be reused
and iterated upon by future organizations of this type. On the other hand, the opportunity to reuse pieces of
previous contracts is certainly far from unique to smart contracts.
/five.lf/three.lf
In other cases, the need for a trusted third party remains. To return to the case of a bet
about the weather, a third party might be employed to input relevant weather information
to the blockchain. In essence, the use of a smart contract here ensures that a certain transfer
of money will occur if a certain report is made, but it does not ensure that the report
will accurately re/fl.ligaect the world. A number of groups, like the Augur team, are working
on consensus and reputation schemes designed to incentivize accurate inputs to smart
contracts [/one.lf/three.lf/zero.lf]. It is still too early, though, to judge how reliable or e/f\_f\_i.ligacient these systems
will be. Existing systems still have very few users and have not been subjected to much
stress-testing. Section /four.lf./two.lf./four.lf discusses the apparent limitations of smart contracts more
thoroughly, with a focus on the ways in which they can introduce new transaction costs as
well.
Here, though, I will walk through a number of domains in which existing institutions
struggle to solve collective action problems. In each case, I will discuss the possibility that
blockchain-associated institutions will be substantially more e/f\_f.ligaective.
Citizens of countries with weak institutions Weak government institutions lead many
countries, especially developing countries, to su/f\_f.ligaer from particularly high transaction
costs. The relevant issues typically include corruption, incompetent government o/f\_f\_i.ligacials
(partly a result of corruption), inconsistent access to services, lack of robust honesty and
reciprocity norms, and so on. High transaction costs associated with such issues have in
turn been linked to low economic growth [/one.lf/two.lf/two.lf]. Notably, even if smart contracts do not
o/f\_f.ligaer advantages over developed world institutions, they could still o/f\_f.ligaer signi/fi.ligacant im-
provements to available institutions outside the developed world. For example, even if
cryptocurrencies are not superior to well-managed /fi.ligaat currencies, citizens of countries
with badly mismanaged currencies (e.g., erratic changes in the rate of in/fl.ligaation) may pre-
fer to rely on cryptocurrencies in some circumstances. Here, the key point is that they
do not need to place their faith in a central bank that might behave irresponsibly or in-
competently. In fact, citizens of certain countries with unreliable /fi.liganancial institutions,
especially citizens of hyperin/fl.ligaation-a/f\_f\_l.ligaicted Venezuela, have taken an unusually large in-
terest in cryptocurrencies [/one.lf/two.lf/zero.lf].
Criminal groups Criminal groups often face barriers to interacting with institutions like
courts, banks, and highly visible reputation systems. It is not possible, for example, to bring
a drug dealer to court for stealing product, or to look up online reviews for hitmen. The
net e/f\_f.ligaect is that groups with an interest in participating in illegal activities are not nearly
so organized or e/f\_f.ligaective as they could be. However, smart contracts may reduce these co-
ordination problems. One paper by Ari Juels, Ahmed Kosba, and Elaine Shi considers the
possibility of “criminal smart contracts,” and describes a range of schemes for using smart
contracts to credibly commit to payments for data leaks, assassinations, and other crimes
[/nine.lf/eight.lf]. Some of these schemes are not yet practical with current smart contract systems. For
example, the scheme for committing to payment for assassinations requires a service that
inputs news to the blockchain as well as a smart contract that is capable of determining
whether a timestamped plan for the assassination, revealed after the event, matches the
news reports. However, some of the other schemes already appear to be relatively practi-
cal, and none appear to face fundamental barriers. If these considerations are combined
/five.lf/four.lf
with the speculative possibility of government surveillance “going dark” (see section /three.lf./one.lf./one.lf),
then it is possible that some forms of illegal activity will become more prevalent in the
future.
Disorganized shared-interest groups It is generally the case, within any given political
system, that only a very small portion of groups with common interests successfully orga-
nize to pursue these interests. For example, private industries often organize to lobby the
government, but the consumers of these industries’ products do not. In/fl.ligauential grassroots
movements have arisen around some issues, like abortion and police violence, but not oth-
ers of comparable concern, like economic policy. The collection of people who would be
happy to become vegetarian if it also meant everyone else did, to pay for news if it also
meant everyone else did, and so on, do not form robust organizations or enter into pacts.
Similarly, even though voters as a whole would have clear common interests in coordi-
nating to become more well-informed, the possibility of such an agreement arising seems
wholly implausible.
These disparities hinge on the fact that, for a su/f\_f\_i.ligaciently large interest group, any individ-
ual member’s contribution to the group’s shared aim will be insigni/fi.ligacant. A single union
member’s dues are unlikely to make a di/f\_f.ligaerence to the union’s bargaining and lobbying
e/f\_f.ligaorts, and a single well-informed voter is unlikely to make a di/f\_f.ligaerence to the quality of
elected o/f\_f\_i.ligacials. If the act of participating in collective action does not bring additional
bene/fi.ligats, and if agreements to participate are di/f\_f\_i.ligacult to enforce, then a rational mem-
ber of a large interest group will refrain from participating. In his classic book The Logic
of Collective Action , the economist Mancur Olson summarizes this point with the thesis,
“Unless the number of individuals in a group is quite small, or unless there is coercion
or some other special device to make individuals act in their common interest, rational,
self-interested individuals will not act to achieve their common or group interests ” [/one.lf/two.lf/three.lf].
According to Olson, many industries are able to organize because they contain only a
relatively small number of decision-making parties, who can direct the employees below
them. Some grassroots movements are able to organize because, due to the nature of their
central issue, membership o/f\_f.ligaers signi/fi.ligacant social bene/fi.ligats, a signi/fi.ligacant personal sense of
meaning, or opportunities to participate in enjoyable activities. Unions in some domains
are able to maintain members due to a mixture of social bene/fi.ligats, control of professional
resources, and opportunities for outright coercion. And so on. The result is an extremely
uneven distribution of power between shared-interest groups, and extremely suboptimal
outcomes for most shared-interest groups—including the group constituted by citizens of
a given country as a whole.
Smart contracts, allowing individuals to credibly commit to collective action if others also
do so, could prove to be a useful tool for many interest groups. Groups interested in fund-
ing lobbying e/f\_f.ligaorts could use smart contracts that result in their making donations only
if enough other people do, too, and perhaps scaling down the donation size as the number
of people who commit grows. The most challenging problem seems to be verifying agree-
ments to take action in the physical world. It is not immediately obvious, for example, how
to credibly commit to attend a protest, become a well-informed voter, or become a vege-
/five.lf/five.lf
tarian. Peer veri/fi.ligacation networks, where members of groups examine evidence produced
by other members, seem possible. These systems could also be engineered to include repu-
tation systems and incentives for honesty. However, each additional unit of human labor,
unit of honesty-inducing incentives, and unit of complexity adds to the total transaction
cost. Plausibly, the total transaction cost could often remain too high to enable collective
action.
It is also not clear that blockchain would resolve the central barrier, whatever it is, that is
preventing these kinds of systems from arising. It is certainly possible to imagine a cen-
tralized Kickstarter-like company that, for example, commits people to make donations
to lobbying groups only if enough other people do too. If the company’s bottom-line de-
pended on the trust of its users, and if it had legal obligations to ful/fi.ligall its commitments,
then a reasonable person should expect the company to follow through and transfer the
funds in an appropriate way. Whatever is preventing these kinds of services from arising,
therefore, might be something other than the need for trusted third parties.
States A central concern in international relations is the relative ine/f\_f\_i.ligacacy of interna-
tional institutions [/nine.lf/three.lf]. Theorists often describe the interactions between countries as
taking place under “anarchy,” since there is no supreme authority capable of /fi.ligalling the
same institutional role that states /fi.ligall at the national level. Many of the greatest problems
in international relations, and therefore many of the largest-scale problems in general,
appear to follow from excessive commitment costs. For example, the possibility of “free-
riding” makes it di/f\_f\_i.ligacult for states to collectively agree to take costly measures to alleviate
environmental issues and global risks, such as those associated with climate change. The
fact that a rising power cannot credibly commit to non-aggression, and the fact that two
mutually hostile nations cannot commit to halting military investment, open the door for
preventative war and arms races [/one.lf/three.lf/three.lf]. In addition, the need to establish the credibility of
one’s commitments, in the absence of other mechanisms, has often been cited as at least a
reason for participating in prolonged wars; the Vietnam War is a notable case. The number
of lives lost, risked, and harmed because of an absence of good tools for making credible
international commitments would be di/f\_f\_i.ligacult to overestimate./four.lf/eight.lf
Therefore, given the stakes, the possibility that smart contracts could have applications
in the international sphere is very much worth investigating. We can construct at least
hypothetical commitment mechanisms that take advantage of smart contracts.
For example, smart contracts might enable countries to more credibly commit to interna-
tional agreements that include penalties for non-compliance. Traditionally, agreements
that include /fi.liganancial penalties, such as the Kyoto Protocol, rely on “self-punishment”
[/nine.lf/five.lf]. Countries that fail to comply with core aspects of the agreement must still, nev-
ertheless, be trusted to comply with the portion that obliges them to pay out large sums of
money. A number of scholars have suggested that the obvious pitfalls associated with “self-
punishment” can be avoided through the use of escrow, with parties to agreements making
initial deposits that are returned only if they demonstrate compliance [/seven.lf/three.lf, /one.lf/one.lf/two.lf]. Smart
/four.lf/eight.lfAt the same time, the ability to make credible commitments is far from being entirely benign [/one.lf/four.lf/two.lf]. Among
other downsides, the ability to credibly commit to threats can increase the ease of extortion.
/five.lf/six.lf
contracts could o/f\_f.ligaer a method for implementing escrow for international agreements,
without the need for a trusted third party to hold and disburse the deposits. In particular,
countries might sign on to a smart contract consenting to the loss of large deposits if a
quorum of other countries, a distributed oracle system, or a set of internet-connected sen-
sors judge that they have violated the agreement; the relevant blockchain could be either
a consortium blockchain held between several countries or a particularly well-established
permissionless blockchain.
As another example, we might also imagine a pair of countries signing onto a smart con-
tract that will deactivate their smart property weapons systems at the same time. The
additional di/f\_f\_i.ligaculty here, though, is the need to /fi.ligarst verify that the weapons systems re-
spond to the state of the blockchain in the appropriate way.
Unfortunately, to be used in such cases the relevant smart contracts would need to become
exceptionally reliable. As section /four.lf./two.lf./one.lf will discuss, this may not be reasonable to expect.
These potential applications of smart contracts to the international sphere are ultimately,
in my view, unlikely. However, if they ever do emerge, then they would probably be the
absolute most consequential applications of smart contracts.
As a /fi.liganal note, this discussion has a close connection to the earlier discussion of the value of
non-intrusive agreement veri/fi.ligacation in the international sphere (see section /three.lf./one.lf./three.lf). Non-
intrusive agreement veri/fi.ligacation can be seen as another tool for lowering commitment
costs, speci/fi.ligacally the costs associated with submitting to monitoring. In the most ideal-
ized case, a state might be forced to reveal no information beyond the simple fact of its
compliance. Likewise, non-intrusive inspection, more generally, can be seen as a tool for
lowering search costs, in that it may reduce any disadvantages states accrue when they
share information that is relevant to bargaining. It is di/f\_f\_i.ligacult, for example, to impress
upon another party the power of one’s cyberweaponry without revealing details that will
make these weapons less e/f\_f.ligaective [/one.lf/zero.lf/six.lf, /one.lf/zero.lf/one.lf]. In general, as James Fearon writes in his classic
paper “Rationalist Explanations for War,” “there is a trade-o/f\_f.liga between revealing informa-
tion about resolve or capabilities to in/fl.ligauence bargaining and reducing the advantages of a
/fi.ligarst strike” [/six.lf/five.lf]. The existence of information asymmetries, due to incentives to maintain
private information, along with commitment problems, are the two most powerful expla-
nations for how mutually harmful wars (and other collective action problems) can arise
even between rational actors.
As with smart contracts, it may not be especially likely, even in the long run, that non-
intrusive inspection will signi/fi.ligacantly lessen international collective action problems. Some
of the most relevant private information—such as the “resolve” of a given state in the lead-
up to a potential war—does not seem to lend itself naturally to tricks with zero-knowledge
proofs and secure multiparty computation. Again, though, the existing problems are of
great enough magnitude that any tool with potential value deserves consideration.
/five.lf/seven.lf
/three.lf./two.lf./four.lf A new variety of institutions, known as “decentralized autonomous organizations,”
could emerge
Some writers have speculated that smart contract technology could allow a new variety
of institutions to emerge. In particular, especially within the Ethereum developer com-
munity, a large number of essays and blog posts have been written on the possibility of
decentralized autonomous organizations. Although de/fi.liganitions vary, we will de/fi.ligane a de-
centralized autonomous organization (DAO) as an organization, associated with its own pool of
assets, in which decisions about how to use these assets are determined by smart contracts
among the organization’s members [/three.lf/six.lf]./four.lf/nine.lf
The /fi.ligarst and still most famous example of a DAO has been a /dollar.lf/one.lf/five.lf/zero.lf million venture capital
fund, known as “the DAO,” which launched on Ethereum in /two.lf/zero.lf/one.lf/six.lf [/one.lf/three.lf/two.lf]. Investors partic-
ipated by buying shares in the fund, then using their shares to vote on how to disburse
the fund’s common pool of cryptocurrency to proposed projects; smart contracts ensured
that this money would be disbursed in accordance with the votes and that pro/fi.ligats from
the projects would be distributed appropriately among the shareholders. Unfortunately,
the DAO came to an untimely end. Within a few days, a user discovered a programming
mistake that allowed them to siphon the majority of funds out of the organization, and,
given that smart contracts are by nature impossible to modify, the project was abruptly
abandoned.
A number of later projects have also described themselves as DAOs [/one.lf/eight.lf/three.lf]. For instance,
similar to “the DAO,” Moloch DAO uses a smart-contract-based system to automatically
disburse cryptocurrency investments if members express enough support for an invest-
ment proposal [/one.lf/six.lf/nine.lf]. Decisions to admit new members are also determined through voting
and processed automatically. Unlike “the DAO,” Moloch DAO does not attempt to make
a pro/fi.ligat. It simply disburses member-provided funds to other blockchain projects that
the community believes are socially valuable and has no mechanism to collect anything
in return. Smart contracts are primarily used to ensure that votes concerning member-
ship expansion and currency disbursement are binding. A failsafe mechanism, designed in
response to the collapse of “the DAO,” also allows members to extract their share of the
common funding pool if they strongly oppose a just-concluded decision concerning the
disbursement of funds.
The few DAOs that exist today are still quite new and, in some ways, fairly rudimentary.
Therefore, given this limited set of case studies, it is di/f\_f\_i.ligacult to draw meaningful gener-
alizations. Still, DAOs do seem to di/f\_f.ligaer from most existing organizations in at least four
interesting ways.
First, DAOs can possess a foundational set of features that is immutable. No party—for
instance, no “leader” of a DAO—can prevent the relevant smart contracts from executing
in the speci/fi.ligaed way. The case of “the DAO” demonstrates the downsides of this property,
but, in the right cases, it can also be considered desirable. DAOs are especially capable
/four.lf/nine.lfSome alternative de/fi.liganitions are loose to the extent that permissionless blockchains themselves constitute
DAOs. Under this conception, the nodes maintaining them act as their “members” and, through cryptocurrency
rewards, share in the “pro/fi.ligats” earned in the process of providing users with a “service.”
/five.lf/eight.lf
of survival and resistance to change, even if there is a complete turnover of members or if
future members are unanimously interested in altering some of their fundamental features.
This steadfastness, even in the face of an opposed membership, is how DAOs earn the
descriptor “autonomous.”
Second, DAOs can be truly transnational. Since they are maintained on blockchains, with
the relevant nodes most likely spread across dozens of countries, they will not have any
particular physical instantiations. In addition, no state can disrupt a DAO—or, at least,
its fundamental features—without doing the costly and potentially unpopular work of
disrupting the blockchain itself. (See section /four.lf./two.lf./three.lf for a discussion of the possibility of
such a disruption.)
Third, depending on the nature of the DAO and the blockchain it is maintained on, indi-
viduals may be able to participate under pseudonyms (typically, the hashes of their public
keys). This form of pseudonymity, while not unheard of, is still rather unusual. The DAO,
for example, was almost certainly the /fi.ligarst-ever pseudonymous eight-/fi.ligagure venture capital
fund.
Fourth, DAOs place an unusually heavy emphasis on complete contracts , or agreements
which precisely specify the obligations of each party for every possible case [/five.lf/six.lf]. Smart
contracts, because they need to be expressed in code, are by nature complete. In tradi-
tional organizations, however, contracts tend to be highly incomplete. In fact, a widely
held theory, associated with the /fi.ligaeld of new institutional economics, is that individuals
form organizations in large part because of the impracticality of specifying complete con-
tracts for the services they provide one another (see section /three.lf./two.lf./one.lf for a discussion of transac-
tion costs) [/one.lf/eight.lf/zero.lf]. Particularly within organizations, interactions tend to be dominated by
relational contracts , which are unwritten cooperative norms that resist formalization [/one.lf/zero.lf].
This body of theory suggests that DAOs are unlikely to be able to e/f\_f\_i.ligaciently replicate the
functionality of most organizations, unless they also rely heavily on more informal rela-
tional contracts in addition to smart contracts. Norms clearly play an important role in
the functioning of Moloch DAO, for instance, since everything other than the enforcement
of votes is managed without smart contracts. One plausible guess we can make about fu-
ture DAOs, at least successful ones, is that they will still mostly be built on top of informal
relational contracts. Nonetheless, even a modestly greater reliance on complete contracts
might lead to interesting structural di/f\_f.ligaerences.
It is interesting to speculate about what future DAOs could look like, conditioning on the
optimistic view that they are in fact plausible outside of a narrow range of cases. What
could a DAO tech company look like? How about a DAO political party, a DAO criminal
organization, or, more fancifully, a DAO state?
Some writers have made quite radical claims about the feasibility of replacing traditional
political systems with DAOs. However, these claims are often ambiguous. As an example,
I will brie/fl.ligay consider the ideas of Ralph Merkle, the inventor of cryptographic hashing,
who has written a paper describing a system of government he calls “DAO democracy”
[/one.lf/one.lf/three.lf].
/five.lf/nine.lf
Merkle’s basic scheme, as described in his paper, is to implement a variant of “futarchy,”
a system of government /fi.ligarst described by the economist Robin Hanson [/eight.lf/six.lf]. In Merkle’s
system, there are annual citizen satisfaction polls, and all citizens are allowed to place bets
on the impact proposed sets of legislation would have on total satisfaction; the sets of leg-
islation that this betting market indicates are most likely to succeed are implemented. To
help secure the integrity of the betting markets, the bets are to be recorded on a consor-
tium blockchain, with the voting power granted to each device being used to maintain the
blockchain determined by further bets about the device’s reliability. Putting aside ques-
tions of this scheme’s practicality, however, it is unclear to what extent it would constitute
a DAO, or whether it would truly require novel cryptographic technology. Merkle makes
no suggestions about the use of smart contracts in the actual implementation of legislation,
and while the use of a consortium blockchains to maintain the betting records seems like
a useful way of increasing their integrity, it also seems somewhat tangential to the overall
vision.
Other writers have explored the argument that blockchains could be a useful tool for ex-
perimenting with novel forms of democracy [/three.lf/seven.lf, /one.lf/five.lf/seven.lf]. Futarchy is often discussed, as is
“liquid democracy,” a system of representative democracy in which individuals can choose
to grant anyone else the power to vote on their behalf for particular sets of decisions; this
representative might in turn pass their accumulated voting power on to a representative
they deem to be even more well-equipped to vote well [/two.lf/three.lf]. Both of these forms of democ-
racy must almost certainly be implemented electronically and require uni/fi.ligaed databases
that are extraordinarily secure. The databases must be trusted to track, for example, active
updates concerning who has the power to vote for whom. Blockchain technology, perhaps
in conjunction with secure multiparty computation, is seen as signi/fi.ligacantly lowering the
trust threshold for implementing these political systems and making it relatively easy for
small (and potentially geographically dispersed) political organizations to trial them. If the
outcomes of votes are more directly linked to tangible outcomes through smart contracts,
then these organizations could, less ambiguously, constitute DAOs.
A number of writers within the blockchain community have suggested that there may
arise DAOs that serve citizens’ needs so su/f\_f\_i.ligaciently that traditional states simply wither
away, or that DAO-based governance will lead people’s political relationships to become
almost entirely decoupled from geography. These are more extreme versions of the visions
discussed in sections /three.lf./two.lf./two.lf and /three.lf./two.lf./three.lf. Marcella Atzori’s paper, “Blockchain Technology and
Decentralized Governance: Is the State Still Necessary?” sympathetically surveys some such
claims, although she ultimately (I believe correctly) /fi.ligands them implausible [/nine.lf].
Finally, we should note that although most current speculation about the political impli-
cations of DAOs seems to be associated with positive visions, it is also possible to imagine
negative outcomes. Intuitively, criminal organizations and terror groups, which may be at
risk of being “beheaded” through the arrest or killing of their leaders, would have incentive
to transform into DAOs if this was feasible. As an example, we can imagine a DAO that
is set up to create “criminal smart contracts” for acts of politically motivated sabotage or
terrorism, using a pool of money contributed by anonymous supporters. (See section /three.lf./two.lf./three.lf
for a brief discussion of criminal smart contracts.)
/six.lf/zero.lf
It must be reiterated, however, that the basic practicality of DAOs, for almost any use case
at all, is still unproven. Smart contracts simply might not be very useful for governing re-
lationships within an organization. This discussion, then, should be regarded as especially
speculative. As section /four.lf./two.lf./four.lf will explore, some very signi/fi.ligacant limitations stand in the
way of the most radical proposed uses of smart contracts becoming feasible.
/six.lf/one.lf
/four.lf Limitations and skeptical views
There are some important roadblocks that could prevent several of the technologies we
have discussed from achieving widespread use or achieving transformative e/f\_f.ligaects. In this
section, I discuss six such roadblocks, which I judge to be particularly signi/fi.ligacant: the in-
e/f\_f\_i.ligaciency of methods of computing on con/fi.ligadential data, the di/f\_f\_i.ligaculty of “scaling” block-
chains, the threat of regulation; the inadequacies of smart contracts, the potential insecu-
rity of permissionless blockchains, and the possibility that existing institutions are “good
enough.”
Other potential roadblocks, which I do not discuss here, include the arrival of quantum
computers (which will render some cryptographic schemes insecure), the “just in case”
data collection practices of many companies (which might make them hesitant to adopt
technologies that reduce or more precisely target their data collection), limited consumer
demand for privacy technologies, and the enormous volume of electricity consumed by
proof-of-work protocols (which could be made unnecessary by a successful shift to proof-
of-stake protocols).
/four.lf./one.lf Limitations of privacy-preserving technologies
/four.lf./one.lf./one.lf The ine/f\_f\_i.ligaciency of computing on con/fi.ligadential data
All methods of running computations on encrypted data—including homomorphic en-
cryption, functional encryption, and secure multiparty computation—add signi/fi.ligacant over-
heads compared to the time and space requirements of computing on unencrypted data.
Although the overheads of secure multiparty computation, especially, are beginning to
become manageable, they may never be entirely negligible. To justify their use, the de-
mand for greater privacy must be enough to o/f\_f.ligaset the economic costs of using MPC. If the
demand is not great enough, then it may never see very broad use.
More troublingly, all known schemes for fully (and somewhat) homomorphic encryption
are so ine/f\_f\_i.ligacient that, at present, it is not possible to use them for anything but extremely
simple computations. This, for example, rules out the possibility of using them to replace
nearly any online service with a privacy-preserving version (see section /three.lf./one.lf) anytime soon. If
fully homomorphic encryption is to /fi.ligand widespread use, there will need to be either major
progress in discovering more e/f\_f\_i.ligacient schemes or a many orders-of-magnitude increase
in available computing power. Still, neither of these possibilities is entirely implausible
due to trends in both the e/f\_f\_i.ligaciency of fully homomorphic encryption and the growth of
computing power [/one.lf/one.lf/seven.lf].
On the other hand, as discussed in section /two.lf./one.lf/three.lf, it may be possible to use secure multiparty
computation to replicate most of the functionality that fully homomorphic encryption can
o/f\_f.ligaer. The extreme ine/f\_f\_i.ligaciency of fully homomorphic encryption could ultimately turn out
to be largely irrelevant.
/six.lf/two.lf
/four.lf./two.lf Limitations of blockchain-based technologies
/four.lf./two.lf./one.lf The di/f\_f\_i.ligaculty of “scaling” permissionless blockchains
As mentioned in section /two.lf./six.lf, the most commonly used permissionless blockchains, such as
Bitcoin and Ethereum, cannot process more than a dozen or so transactions per second. In
comparison, a company like Visa can process tens of thousands of transactions per second
by using ordinary servers.
Low transaction speeds limit the number of users a blockchain can plausibly sustain, as
well limiting the complexity of the services a blockchain can provide [/five.lf/four.lf]. Almost cer-
tainly, the most optimistic visions of blockchain’s potential—such as the vision that de-
centralized cryptocurrencies will signi/fi.ligacantly compete with /fi.ligaat currencies (see section
/three.lf./two.lf./two.lf), the vision that decentralized applications will replace a large portion of traditional
online applications (see section /three.lf./two.lf./two.lf), or the vision that smart contracts will enable the
creation of vast new political entities (see section /three.lf./two.lf./four.lf)—can only be realized by permis-
sionless blockchains with much higher processing speeds. Low processing speeds can also
indirectly limit the security of permissionless blockchains by limiting the total value of
transaction fees collected by actors maintaining them: typically, the more wealth one can
collect from transaction fees, the greater the incentives to maintain a given blockchain will
be.
The most fundamental source of the problem, here, is that traditional blockchains such as
Bitcoin require all of the nodes maintaining the blockchain to process each transaction,
rather than splitting the labor between nodes. Such blockchains do not scale, in the sense
that adding more processors or faster processors to the network does nothing to increase
the system’s overall processing speed. The system cannot process transactions any faster
than the slowest computer (also taking into account its network connection) that is capable
of serving as a node. The need for nodes to communicate with one another and come to
consensus then introduces further delays.
There are two main strategies for addressing the scaling problem. The /fi.ligarst strategy is to
implement sharding [/six.lf/zero.lf]. This involves splitting a blockchain into multiple shards, with
each shard handling a subset of transactions. Then, some nodes can opt to be involved in
only a single shard. The more shards there are, the lower the minimum burden is on each
node.
There are some obvious challenges that any successful sharding scheme must overcome:
developers must prevent successful attacks on individual shards, must allow the shards
to interface with each other, and must generally ensure security and consistency despite
division. A great deal of research within the blockchain community is currently devoted
to overcoming these challenges.
The other strategy is to pursue layer /two.lf scaling . This involves outsourcing a large portion
of necessary computations to external processors rather than requiring all of the nodes
maintaining the blockchain to perform them [/six.lf/two.lf]. State channels allow groups of users
to make sequences of transactions among themselves and then only publish the /fi.liganal re-
/six.lf/three.lf
sult to the blockchain. For example, if ownership of a token is transferred multiple times
within a short interval, then state channels could remove the need for blockchain nodes
to process the intermediate transactions. Similarly, rollups allow external computers to
process batches of transactions “o/f\_f.liga-chain” and then record only the /fi.liganal state update to
the blockchain. Of course, to avoid a large loss in security, there needs to be some way to
verify that these kinds of external computations have been performed correctly. Succinct
cryptographic proofs known as zk-SNARKs (see section /two.lf./eight.lf) are one important tool for
supporting veri/fi.ligacation. These proofs, which can be published to the blockchain, allow
the nodes maintaining a blockchain to verify that some computation has been carried out
correctly without needing to rerun the full computation themselves.
A number of teams are currently working to upgrade the Ethereum blockchain by devel-
oping and implementing a mixture of sharding and layer /two.lf scaling techniques. The most
optimistic community members expect these upgrades to allow Ethereum to process tens
of thousands of times more transactions per second. It remains to be seen, though, just
how successful these approaches to the scaling problem will be.
There are also some projects that have pursued performance gains without addressing the
fundamental scaling problem. In general, these projects have set higher minimum perfor-
mance standards for participating nodes, have reduced certain ine/f\_f\_i.ligaciencies involved in
decentralized consensus protocols, or have done some combination of the two. Litecoin is
an early and well-known example of a blockchain project that has achieved modest perfor-
mance gains by raising the minimum performance requirements for individual nodes. To
explain, blockchain protocols typically aim for a roughly constant rate of block creation
and typically place a hard limit on how many transactions can be included in a single block.
These two design constraints then imply a limit on the rate at which transactions can be
processed. For example, because the Bitcoin blockchain gains an average of six new blocks
per hour, and these blocks are each only allowed to contain a few thousand transactions,
there is no way for Bitcoin to process more than a dozen or so transactions per second.
Litecoin and a number of other blockchains have achieved higher processing speeds, rel-
ative to Bitcoin, partly by using larger “block sizes.” However, increasing the block size
has also raised the minimum performance standards that nodes must meet to pro/fi.ligatably
participate in maintaining the blockchain./five.lf/zero.lf
A more recent and promising example of a blockchain project that eschews sharding and
layer-/two.lf solutions is Solana. Solana’s designers have developed a consensus protocol that re-
quires an unusually small amount of communication and produces agreement between the
participating nodes unusually quickly [/one.lf/eight.lf/four.lf]. The overall speed of the blockchain is there-
fore not much slower than the speed at which an individual node can process transactions.
Due to comparatively high minimum performance standards for nodes, it is reportedly
able to process tens of thousands of transactions a second. As the Solana project is still in
/five.lf/zero.lfSince there is always some cost involved in maintaining a blockchain, nodes are only likely to earn a pro/fi.ligat
if they are able to process transactions at the maximum rate that the blockchain allows. A slow node that tries
to participate will only be able to process a fraction of the transactions that faster nodes can. It will therefore
only be able to collect a fraction of the total transaction fees that these other nodes can. Ultimately, one should
expect nodes that fall below some minimum speed threshold to drop o/f\_f.liga the network.
/six.lf/four.lf
its “beta phase,” there is some lingering uncertainty about the system’s security and long-
term stability. Nonetheless, at the time of writing, it is perhaps the fastest decentralized
blockchain system.
One general observation is that raising the minimum performance standards for a block-
chain’s nodes will typically allow the blockchain to support more computationally inten-
sive applications, but will also, typically, reduce the number of actors who are capable
of helping to maintain or audit the blockchain. Projects such as Solana therefore must
navigate a fairly direct trade-o/f\_f.liga between performance and centralization. This trade-o/f\_f.liga
should be less sharp for blockchain projects that attempt to address the fundamental scal-
ing problem by relying on techniques such as sharding and rollouts since these projects
achieve performance gains primarily by reducing the amount of computation that individ-
ual nodes are asked to do.
Time will tell whether any of these strategies—or some combination of them—will be
enough to enable applications that are both highly decentralized and highly performant.
However, the past few years of research progress seem to support an at least moderate
degree of optimism.
/four.lf./two.lf./two.lf The threat of restrictive regulations
A simple way to limit the use of a technology is to regulate it.
In the case of public-key cryptography, the oldest of the technologies we have discussed
here, there is a long history of countries deliberating on how best to regulate it. As re-
cently as the /one.lf/nine.lf/nine.lf/zero.lfs, for example, law enforcement agencies in the United States were ar-
guing that the use of encryption that they could not themselves decrypt should be made
illegal [/one.lf/one.lf]. For the time being, all forms of encryption are perfectly legal to use within
the United States and European Union, with most other major countries placing only rel-
atively limited restrictions on use [/one.lf/four.lf/zero.lf]. However, it is not certain that the status quo will
never change. Especially in the wake of terror attacks or other catalyzing events, it is not
uncommon for law enforcement o/f\_f\_i.ligacials or politicians to re-propose restrictions on cryp-
tography, particular the use of end-to-end encryption [/four.lf/four.lf, /nine.lf/two.lf]. A fairly recent development
is China’s decision to block the use of WhatsApp, apparently based on WhatsApp’s use of
end-to-end encryption [/three.lf/zero.lf].
In the case of more novel cryptographic technologies, such as cryptocurrencies, legal sta-
tuses are in something of a state of /fl.ligaux, with regulations varying substantially by country
and by state [/four.lf/six.lf]. Regulations tend to focus on points of contact between permissionless
blockchains and the outside world—for example, on businesses that exchange traditional
currency for cryptocurrency—due in large part to the fact that these blockchains are inher-
ently di/f\_f\_i.ligacult to interfere with and lack any discernible party that is in “control” of them
[/one.lf/six.lf/eight.lf, /one.lf/zero.lf/two.lf]. For instance, know-your-customer (KYC) laws, which compel cryptocurrency ex-
changes to record and verify the identities of their customers, have become increasingly
common.
It is unclear to what extent the regulation of emerging cryptographic technologies is likely
/six.lf/five.lf
to limit their use, especially given that blockchains themselves are so di/f\_f\_i.ligacult to inter-
fere with. Still, if the technologies ever become truly threatening, for instance by creating
/fi.liganancial instability or by making it easier for terror groups to operate, then dramatic ac-
tions by major governments are not inconceivable. A simple action in this category might
be banning cryptocurrency exchanges, making it di/f\_f\_i.ligacult for individuals to purchase cryp-
tocurrency or to “cash out” by exchanging their cryptocurrency for traditional currency.
States may also directly ban the use of cryptocurrencies or the use of certain decentral-
ized applications. Although a complete ban would probably be very di/f\_f\_i.ligacult to enforce,
it should at least be possible, for example, to prevent large domestic businesses from ac-
cepting cryptocurrency payments./five.lf/one.lfThe most extreme suppression strategy might be to
attempt to “take over” proof-of-work blockchains by directing large amounts of computing
power toward cryptocurrency mining, while attempting to disrupt other mining groups.
(See section /four.lf./two.lf./three.lf for a discussion of the potential dynamics of a take-over attempt.) E/f\_f.ligaorts
to vigorously regulate these technologies, rather than suppress them, might also introduce
various frictions or limitations that reduce their appeal.
It seems reasonable to speculate that if regulation signi/fi.ligacantly in/fl.ligauences the use of crypto-
graphic technologies, it will primarily limit the uses that increase the di/f\_f\_i.ligaculty of surveil-
lance (see section /three.lf./one.lf./one.lf), lessen the in/fl.ligauence of economic and political institutions like cen-
tral banks (section /three.lf./two.lf./two.lf), make it easier for threatening actors to coordinate (section /three.lf./two.lf./three.lf),
or enable the creation of new decentralized political actors (section /three.lf./two.lf./four.lf). In short, the
uses of cryptography that are most desired by the libertarian and anarchist portions of the
cryptography community may also be the ones that are most di/f\_f\_i.ligacult to achieve.
/four.lf./two.lf./three.lf The potential insecurity of permissionless blockchains
As discussed in section /two.lf./six.lf./three.lf, permissionless blockchains are maintained through fairly
complex consensus protocols. In short, they work by allowing any user to participate in
the maintenance of the blockchain, granting these users voting power over the blockchain’s
contents in proportion to the amount of some scarce resource they own (such as computing
power), and incentivizing them to vote honestly by making it very likely that they will earn
digital currency if they do (or lose digital currency if they do not).
There are two interrelated problems with these protocols: First, there may be a natural
tendency for large portions of scarce resources to eventually end up in the control of a very
small number of users. Second, especially for users who control large portions of scarce
resources, there may be ways to earn money or achieve desirable outcomes other than by
helping to maintain the blockchain honestly [/one.lf/one.lf/nine.lf].
We will /fi.ligarst consider the case of the Bitcoin blockchain, which is by far the most well es-
tablished. Bitcoin, as a reminder, uses a proof-of-work protocol that forces users known as
“miners” to demonstrate their ownership of computing power by solving resource-intensive
puzzles.
/five.lf/one.lfA handful of states, including Pakistan and Vietnam, have banned cryptocurrency ownership and use out-
right [/one.lf/five.lf/three.lf]. At the time of writing, India is also considering a complete ban [/three.lf]. So far, though, there is not much
evidence for the e/f\_f\_i.ligacacy of bans. In Vietnam, for instance, /two.lf/one.lf% of respondents in a /two.lf/zero.lf/two.lf/one.lf survey reported owning
or using cryptocurrencies [/three.lf/three.lf]. This is the second-highest rate in the world.
/six.lf/six.lf
As of /two.lf/zero.lf/two.lf/one.lf, four mining collectives collectively controlled more than /five.lf/zero.lf% percent of the
computing power directed at mining Bitcoin [/one.lf/five.lf/five.lf]. If they decided to collude to “dou-
ble spend” coins, then they could produce a dishonest version of the Bitcoin blockchain,
missing records of their previous expenditures, that outpaces the honest one.
Mining operations may have a natural tendency to become centralized in this way, as
races to develop and buy up specially built systems for solving puzzles can quickly be-
come prohibitively expensive for all but a few parties. The need for mining groups to
insure themselves against unlucky streaks can then provide a further incentive for them to
merge.
Furthermore, at least for Bitcoin, it is apparently not the case that more than half of the
relevant computing power needs to be directed in a dishonest way for a dishonest version
of the blockchain to win out. Researchers have identi/fi.ligaed a strategy that colluding Bitcoin
miners with only /two.lf/five.lf% control could use to springboard themselves into majority control
and begin to take self-enriching actions, like spending individual coins multiple times
[/six.lf/four.lf].
If other users become aware that a given blockchain has been subjected to an attack of this
sort, as would almost certainly happen, one plausible result is that the associated cryp-
tocurrency would have its exchange value abruptly drop. This potential fallout might be
enough to keep miners from colluding, even if they would otherwise ostensibly stand to
gain, since the value of their accumulated bitcoin and their investments into specialized
mining hardware depend on the exchange rate for the coin.
However, this incentive-based safeguard would not necessarily be enough for parties that
wish to disrupt the blockchain for reasons other than simple /fi.liganancial exploitation. For
instance, if the government of a large country really wanted to disrupt Bitcoin, it would
need to invest in the computing power necessary to gain majority control.
In such a case, if the honest parties using a blockchain come to recognize that the major-
ity of computing power is being directed dishonestly, which should in practice be quite
conspicuous, then they can create what is known as a forkof the blockchain [/one.lf/one.lf/nine.lf]. This is
accomplished by having a large portion of honest users update their software to disregard
blocks now known to have been proposed by dishonest users, building on top of blocks
further back in the chain’s history. The “fork” is a new, diverging blockchain that, if socially
acknowledged, can /fi.ligall the role of the initial one.
However, in the event of a fork, the dishonest users could still “spawn camp” by adopting
new public-key pseudonyms and using their computing power to once again take control of
the newly forked blockchain. The honest users might, as a further response, update to a new
software version whose mining puzzles the attackers’ hardware is less suited for—but, even
if this move is taken, attackers with su/f\_f\_i.ligacient resources could still make the blockchain
unusable. Repeatedly disrupting Bitcoin would be an expensive venture—likely costing
billions of dollars—but could in principle be done./five.lf/two.lf
/five.lf/two.lfAs a further point, a highly empowered attacker (such as a national government) might also be able to
/six.lf/seven.lf
In short, like any other system of storing data, Bitcoin is not invincible. Its security can
be thought of as roughly proportional to the total computing power devoted to mining, as
the greater this number is, the more money miners have to lose by tanking the blockchain
and the more money another attacker would need to spend to gain enough computing
power. If insu/f\_f\_i.ligacient computing power is invested, then Bitcoin—and other blockchains
using proof-of-work—will remain insu/f\_f\_i.ligaciently reliable to use for any truly vital applica-
tions.
Proof-of-stake blockchains have similar limitations but are perhaps more promising. For
them, each node’s voting power is made proportional to the quantity of cryptocurrency
it “deposits.” Then, the option of applying cryptocurrency penalties to parties that vote
dishonestly can help strengthen incentives, and the possibility of forking to completely
disregard the currency previously owned by an attacking party can help to remove the
possibility of “spawn camping.”
For proof-of-stake systems, security is roughly proportional to the value of the relevant
cryptocurrency deposits, so it can also be expected to increase as more value is tied up
in the relevant blockchain. It follows that the potential security that can be o/f\_f.ligaered by a
given proof-of-stake blockchain is linked to its scalability—in other words, as discussed
in section /four.lf./two.lf./one.lf, whether it can be made to accommodate a much larger number of users
and transactions. Plausibly, a su/f\_f\_i.ligaciently scalable proof-of-stake blockchain—like what
Ethereum aims to become—could be extremely secure. However, proof-of-stake protocols
are still too new for their superiority to proof-of-work protocols to be clear. The relative
merits of proof-of-stake systems and proof-of-work systems are still debated within the
blockchain community.
In summary, it is not yet clear exactly how much security permissionless blockchains can
o/f\_f.ligaer. If new weaknesses are discovered, or existing weakness become more salient with
time, then many users may not feel comfortable using permissionless blockchains for cer-
tain purposes. For example, even once-in-a-decade failures could be enough to heavily
disincentivize the use of cryptocurrencies as stores of value.
/four.lf./two.lf./four.lf The inadequacies of smart contracts
As discussed in section /three.lf./two.lf./three.lf, one way to conceptualize smart contracts is as a tool for
reducing the “transaction costs” associated with entering into agreements.
To return once more to an illustrative example, a chess smart contract can allow two parties
to agree to have whoever loses the game pay the winner, without the need to establish trust
between the parties, to risk their non-compliance, or to enlist the services of a third-party
enforcer. Since there is a wide range of cases where existing institutions leave transaction
costs quite high—with, for example, ine/f\_f\_i.ligacient legal systems being a common problem—it
is a natural hypothesis that smart contracts will be helpful for some of these cases.
Section /three.lf./two.lf./three.lf lists, at a rather abstract level, a number of ways in which smart contracts
decrease honest miners’ power by shutting down mining facilities, restricting the sale of specialized hardware, or
applying other controls.
/six.lf/eight.lf
Search costs Bargaining costs Commitment costs
•Verifying smart
contract traits
•Establishing
con/fi.ligadence in smart
property
•Learning about
cryptographic tools•Formulating complete
contracts
•Translating contracts
into computer code•Paying fees to full
nodes
•Paying fees to
information
services
•Protecting against
coercion and theft
of digital assets
•Risking failure of
smart contract to
function as
expected
Table /five.lf: New transaction costs associated with smart contract use
may reduce transaction costs. The section then considers the possibility that, on this basis,
they may be able to solve some collective action problems that existing institutions either
cannot solve or can only solve relatively ine/f\_f\_i.ligaciently.
At the same time, it is important to note that smart contracts introduce new transaction
costs of their own. These costs imply that using smart contracts may also, in many cases,
be a far inferior alternative to existing institutions. I will consider search costs, bargaining
costs, and then commitment costs.
Concerning search costs, there will be the cost of verifying that a smart contract conforms
to the relevant parties’ intentions. The importance of veri/fi.ligacation is illustrated by the fail-
ure of the multimillion-dollar venture capital fund “the DAO” (discussed in section /three.lf./two.lf./four.lf).
An unfortunate programming mistake in the relevant smart contracts, not noticed until
it was too late, left open a loophole that allowed one user to siphon a large portion of the
money out of the fund [/six.lf/seven.lf]. The more complex a smart contract is, the more di/f\_f\_i.ligacult the
work of detecting such /fl.ligaaws will be. While the techniques of formal veriﬁcation can help in
checking that a smart contract has certain mathematically well-de/fi.liganed properties, there
will still remain the more nebulous task of checking that the potential judgements of a
smart contract all conform to common sense [/two.lf/one.lf]. In this vein, the fact that traditional
agreements can be /fi.ligaltered through human interpretation, which is capable of navigating
ambiguities and grasping obvious intentions, can be seen as an important cost-saving fea-
ture.
In cases where smart contracts involve smart property, there will also be the search cost
of establishing trust that a piece of smart property does in fact respond to the relevant
blockchain in the promised way. Conceivably, a regulatory system could be required to
establish this trust (see section /four.lf./two.lf./two.lf). Another simple search cost, which we might regard
/six.lf/nine.lf
as something of a /fi.ligaxed cost, is the cost of learning about smart contracts and how to use
them. As the length of this report may help to demonstrate, this cost should be regarded
as non-trivial.
Concerning bargaining costs, it may often be very di/f\_f\_i.ligacult to develop smart contracts that
arecomplete , meaning that they precisely specify the obligations of each party for every pos-
sible case. As smart contracts are computer code, designed to execute automatically, they
do not leave room for ambiguity or underspeci/fi.ligacation. However, many legal scholars and
economists hold that incomplete contracts are dramatically more common than complete
ones [/one.lf/six.lf/three.lf, /eight.lf/nine.lf]. The reason is that, for complex transactional relationships, it can be excep-
tionally di/f\_f\_i.ligacult to translate each party’s obligations into something so precise as computer
code while su/f\_f\_i.ligaciently accounting for every possible future contingency. Should the need
arise for a traditional contract, ambiguities and contingencies can be e/f\_f.ligaectively /fi.ligalled in
after an initial agreement, through ad hoc renegotiation and the cooperative norms that
characterize informal “relational contracts” [/one.lf/zero.lf]. In contrast, smart contracts place the full
burden on working out the contract’s details on the initial drafters. In many cases, this is
likely to be impractical./five.lf/three.lf
We also have particular reason to doubt that most traditional organizations could be e/f\_f\_i.liga-
ciently reconstructed as smart-contract-based “decentralized autonomous organizations”
(see section /three.lf./two.lf./four.lf). A widely held theory in economics is that hierarchical /fi.ligarms arise, in
large part, because of the impracticality of drafting complete contracts [/eight.lf/nine.lf, /one.lf/eight.lf/zero.lf]. As a
trivial example, a company’s employees do not need to treat each idiosyncratic e-mail they
send out as a service requiring formal contractual representation. The members of a DAO,
at least a DAO that makes truly extensive use of smart contracts, may not have this lux-
ury.
Then, there are commitment costs.
First, there are the costs associated with the need to maintain the integrity and availability
of the underlying blockchain. These costs consist of fees for creating and interacting with
smart contracts, which, at least in the case of permissionless blockchains, feed into the
cryptocurrency rewards used to incentivize full nodes to store and execute these contracts
(see section /two.lf./six.lf./two.lf). Since all of the nodes must perform the same work, at least in traditional
blockchain systems, these fees can become quite signi/fi.ligacant. For example, in any case where
a traditional online service is not associated with either extremely high pro/fi.ligat margins or
signi/fi.ligacant regulatory burdens, an equivalent decentralized application will normally be
much more expensive to use.
Second, in cases where users would like to make a contract conditional on features of
the outside world, such as one party’s success in /fi.liganishing a construction project on time,
there will be costs associated with ensuring that this information is recorded properly.
The relevant parties may need to acquire the services of a trusted third-party arbiter or
/five.lf/three.lfAnother cause for concern comes from the long-standing /fi.ligaeld of “computational law,” which has examined
the possibility of translating laws and contracts into computer code and found that, while translation may be
feasible within some domains (including electronic commerce), judgements often require case-based, analogical,
or inductive reasoning that it is very di/f\_f\_i.ligacult to represent with computer code [/seven.lf/one.lf, /one.lf/four.lf/seven.lf].
/seven.lf/zero.lf
apply a distributed consensus protocol that uses cryptocurrency payouts to incentivize
multiple parties to converge on the truth. As mentioned in section /two.lf./one.lf/zero.lf, some developers
are currently trialing early versions of these consensus protocols. However, it remains to
be seen how e/f\_f.ligaective “distributed oracle systems“ will be. In general, large expenditures
could be required to create su/f\_f\_i.ligacient incentives for accurate inputs.
Third, there will be costs associated with the need to ensure that theft or coercion cannot
be applied to counteract a smart contract. For example, the relevant parties must pro-
tect against their private keys being stolen, as well as having any of their smart property
stolen and rewired. More bluntly, the parties must protect themselves against attempts to
threaten them into signing unfavorable contracts. The necessary security measures may be
expensive. These security concerns are also, of course, good arguments for the continued
relevance of existing law enforcement institutions. The potential need to interact with
these institutions adds its own costs.
Finally, there will be the costs associated with the risk that a contract does not function as
expected. Despite the relevant parties’ best e/f\_f.ligaorts, a contract’s code may contain errors,
the consensus protocols used to maintain the blockchain may fail (see section /four.lf./two.lf./three.lf), the
external information the contract relies on may be inaccurate, the parties may experience
theft or coercion, or the expected signi/fi.ligacance of the relevant digital assets may fail to
hold, for example, if a cryptocurrency loses its value or if a piece of smart property does
not respond as promised. Collectively, these risks may be quite signi/fi.ligacant.
Together, all these considerations suggest that, while smart contracts may help to reduce
some transaction costs, they also come with very signi/fi.ligacant costs of their own. There is
not yet an obvious basis for predictions that they will heavily encroach on the territory
already covered by existing institutions (see section /three.lf./two.lf./two.lf).
/four.lf./two.lf./five.lf The possibility that existing institutions are “good enough”
The previous section explored the various inadequacies of smart contracts. A somewhat
symmetrical viewpoint—which pushes against the idea that smart contracts, and decen-
tralized applications generally, will begin /fi.ligalling many of the functions /fi.ligalled by existing
institutions (see section /three.lf./two.lf./two.lf)—is that many existing institutions are actually highly e/f\_f.ligaec-
tive [/one.lf/five.lf/six.lf].
Overall, the most compelling arguments for the use of permissionless blockchain technol-
ogy seems to be an argument from commitment costs (see section /three.lf./two.lf./three.lf). In particular,
in certain circumstances, this technology can limit the costs associated with the need to
establish trust in other parties to provide services, as well as with the risk of having this
trust violated.
Nevertheless, the case can be made that, in the current institutional environment, trust is
often fairly easy to come by. As Vitalik Buterin writes in his essay, “The Problem of Trust,”
“At least in the developed world, if you put your money in a bank, it’s safe.... From such
a perspective, one can easily see how the traditional ‘centralized system’ is serving people
just /fi.ligane” [/three.lf/nine.lf].
/seven.lf/one.lf
To be sure, there are many cases where trust is not easy to come by. Section /three.lf./two.lf./three.lf discusses
some of them, including cases where the relevant parties are located in countries with un-
usually dysfunctional institutions. It is unclear, though, just how far these cases extend,
or exactly how e/f\_f.ligaective blockchain systems could be for resolving them. While polls show
that citizens in many countries report distrusting major political and economic institu-
tions, their levels of trust may still, as a relative matter, be much greater than they would
be for complicated and unproven cryptographic technologies [/one.lf/two.lf/seven.lf, /eight.lf/eight.lf].
In his essay, Buterin acknowledges these points, but also takes a long-run perspective to
caution against what he might consider excessive skepticism. First, he writes, decentralized
applications could eventually establish much greater reputations for trustworthiness than
they possess today:
Who would you really trust more: [well-vetted banks] or a group of mining ﬁrms of
unknown quantity and size with no real-world reputations, /nine.lf/zero.lf% of whose chips may
be produced in Taiwan or Shenzhen? For mainstream securities settlement, the answer
that most people in the world would give seems rather clear. But then, in ten years’
time, if the set of miners or the set of anonymous stakeholders of some particular
currency proves itself trustworthy, eventually banks may warm up to even the more
“pure cryptoanarchic” model – or they may not.
Second, in some cases, it may be more appropriate to think of blockchain technology as
cutting the costs a new institution must face in earning su/f\_f\_i.ligacient quantities of trust:
Rather than concentrating on the lack of trust, here we emphasize the barrier to en-
try in becoming a locus of trust. Sure, billion dollar companies can certainly become
loci of trust just ﬁne, and indeed it is the case that they generally work pretty well....
However, their ability to do so comes at a high cost.... The key promise of decen-
tralized technology, under this viewpoint, is not to create systems that are even more
trustworthy than current large institutions.... Rather, the key promise of decentral-
ized technology is to provide a shortcut to let future application developers get there
faster.... A [simple cryptographic protocol] may well have a lower probability of failure
than all but the largest of institutions – and at a millionth of the cost. Blockchain-
based applications allow developers to prove that they are honest – by setting up a
system where they do not even have any more power than the users do.
This consideration seems to suggest that, if decentralized applications do eventually achieve
a prominence comparable to existing centralized institutions, it may not be by directly dis-
placing them. Instead, these systems might /fi.ligall voids left by institutions that su/f\_f.ligaer losses
of trust, or o/f\_f.ligaer future services that no institution yet provides. The rise of blockchain
technology in political and economic life could be gradual, like the turnover of cells in a
body.
Nevertheless, even this more moderate view is highly speculative. As the preceding sec-
tions have discussed, there remain di/f\_f\_i.ligacult technical and legal roadblocks to large-scale
blockchain use, and the utility of smart contracts is still extremely unclear. A vast gap
separates the technology’s present level of maturity and the level of maturity it will need
/seven.lf/two.lf
to achieve to o/f\_f.ligaer plausible alternatives to most of the services provided by centralized
institutions.
Since blockchain technology is only a dozen years old, and has attracted widespread at-
tention for perhaps /fi.ligave years, it would appear premature to place a cap on its potential.
However, it would also be premature to forecast radical visions with any degree of con/fi.liga-
dence.
/seven.lf/three.lf
References
[/one.lf] S. Aaronson, “Quantum copy-protection and quantum money,” in /two.lf/zero.lf/zero.lf/nine.lf /two.lf/four.lfth An-
nual IEEE Conference on Computational Complexity . IEEE, /two.lf/zero.lf/zero.lf/nine.lf, pp. /two.lf/two.lf/nine.lf–/two.lf/four.lf/two.lf,
doi:/one.lf/zero.lf./one.lf/one.lf/zero.lf/nine.lf/CCC./two.lf/zero.lf/zero.lf/nine.lf./four.lf/two.lf.
[/two.lf] C. C. Aggarwal and S. Y. Philip, “A general survey of privacy-preserving data mining
models and algorithms,” in Privacy-preserving data mining , C. C. Aggarwal and S. Y.
Philip, Eds. New York: Springer, /two.lf/zero.lf/zero.lf/eight.lf, pp. /one.lf/one.lf–/five.lf/two.lf.
[/three.lf] A. Ahmed and N. Anand, “India to propose cryptocurrency
ban, penalising miners and traders,” Reuters , /two.lf/zero.lf/two.lf/one.lf. [Online]. Avail-
able: https://www.reuters.com/article/uk-india-cryptocurrency-ban/india-to-
propose-cryptocurrency-ban-penalising-miners-traders-source-idUSKBN/two.lfB/six.lf/zero.lfQP
[/four.lf] G. Allen and T. Chan, “Arti/fi.ligacial intelligence and national security,” Belfer
Center for Science and International A/f\_f.ligaairs, Harvard Kennedy School, /two.lf/zero.lf/one.lf/seven.lf. [On-
line]. Available: https://www.belfercenter.org/publication/arti/fi.ligacial-intelligence-
and-national-security
[/five.lf] D. Amodei, C. Olah, J. Steinhardt, P. Christiano, J. Schulman, and D. Mané,
“Concrete problems in AI safety,” arXiv preprint arXiv:/one.lf/six.lf/zero.lf/six.lf./zero.lf/six.lf/five.lf/six.lf/five.lf, /two.lf/zero.lf/one.lf/six.lf. [Online].
Available: https://arxiv.org/abs//one.lf/six.lf/zero.lf/six.lf./zero.lf/six.lf/five.lf/six.lf/five.lf
[/six.lf] J. V. Andrew J. Coe, “Why arms control is so rare,” American Political Science Review ,
vol. /one.lf/one.lf/four.lf, no. /two.lf, pp. /three.lf/four.lf/two.lf–/three.lf/five.lf/five.lf, /two.lf/zero.lf/two.lf/zero.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/one.lf/seven.lf/S/zero.lf/zero.lf/zero.lf/three.lf/zero.lf/five.lf/five.lf/four.lf/one.lf/nine.lf/zero.lf/zero.lf/zero.lf/seven.lf/three.lfX.
[/seven.lf] J. Andrews, “An introduction to AZTEC,” /two.lf/zero.lf/one.lf/nine.lf. [Online]. Available: https:
//medium.com/aztec-protocol/an-introduction-to-aztec-/four.lf/seven.lfc/seven.lf/zero.lfe/eight.lf/seven.lf/five.lfdc/seven.lf
[/eight.lf] L. J. Aslett, P. M. Esperança, and C. C. Holmes, “A review of homomorphic
encryption and software tools for encrypted statistical machine learning,” /two.lf/zero.lf/one.lf/five.lf,
arXiv preprint arXiv:/one.lf/five.lf/zero.lf/eight.lf./zero.lf/six.lf/five.lf/seven.lf/four.lf. [Online]. Available: https://arxiv.org/abs//one.lf/five.lf/zero.lf/eight.lf.
/zero.lf/six.lf/five.lf/seven.lf/four.lf
[/nine.lf] M. Atzori, “Blockchain technology and decentralized governance: Is the state still
necessary?” /two.lf/zero.lf/one.lf/five.lf, doi:/one.lf/zero.lf./two.lf/one.lf/three.lf/nine.lf/ssrn./two.lf/seven.lf/zero.lf/nine.lf/seven.lf/one.lf/three.lf.
[/one.lf/zero.lf] G. Baker, R. Gibbons, and K. J. Murphy, “Relational contracts and the theory
of the /fi.ligarm,” The Quarterly Journal of Economics , vol. /one.lf/one.lf/seven.lf, no. /one.lf, pp. /three.lf/nine.lf–/eight.lf/four.lf, /two.lf/zero.lf/zero.lf/two.lf,
doi:/one.lf/zero.lf./one.lf/one.lf/six.lf/two.lf//zero.lf/zero.lf/three.lf/three.lf/five.lf/five.lf/three.lf/zero.lf/two.lf/seven.lf/five.lf/three.lf/three.lf/nine.lf/nine.lf/four.lf/four.lf/five.lf.
[/one.lf/one.lf] D. Banisar, “Stopping science: The case of cryptography,” Health Matrix , vol. /nine.lf,
no. /two.lf, pp. /two.lf/five.lf/three.lf–/two.lf/eight.lf/seven.lf, /one.lf/nine.lf/nine.lf/nine.lf. [Online]. Available: https://scholarlycommons.law.case.
edu/healthmatrix/vol/nine.lf/iss/two.lf//four.lf/
[/one.lf/two.lf] B. Barrett, “The year encryption won,” Wired , /two.lf/zero.lf/one.lf/six.lf. [Online]. Available:
/seven.lf/four.lf
https://www.wired.com//two.lf/zero.lf/one.lf/six.lf//one.lf/two.lf/year-encryption-won/
[/one.lf/three.lf] C. P. Bauer, Secret history: The story of cryptology . Boca Raton, FL: CRC Press, /two.lf/zero.lf/one.lf/three.lf.
[/one.lf/four.lf] C. Baum, I. Damgård, and C. Orlandi, “Publicly auditable secure multi-party
computation,” in International Conference on Security and Cryptography for Networks .
Springer, /two.lf/zero.lf/one.lf/four.lf, pp. /one.lf/seven.lf/five.lf–/one.lf/nine.lf/six.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/three.lf/one.lf/nine.lf-/one.lf/zero.lf/eight.lf/seven.lf/nine.lf-/seven.lf\_/one.lf/one.lf.
[/one.lf/five.lf] BBC Editors, “What are NFTs and why are some worth millions?” BBC News , /two.lf/zero.lf/two.lf/one.lf.
[Online]. Available: https://www.bbc.com/news/technology-/five.lf/six.lf/three.lf/seven.lf/one.lf/nine.lf/one.lf/two.lf
[/one.lf/six.lf] M. Ben-Or, O. Goldreich, S. Goldwasser, J. Håstad, J. Kilian, S. Micali, and
P. Rogaway, “Everything provable is provable in zero-knowledge,” in Advances in
Cryptology–CRYPTO /one.lf/nine.lf/eight.lf/eight.lf . Springer-Verlag, /one.lf/nine.lf/nine.lf/zero.lf, pp. /three.lf/seven.lf–/five.lf/six.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//zero.lf-/three.lf/eight.lf/seven.lf-
/three.lf/four.lf/seven.lf/nine.lf/nine.lf-/two.lf\_/four.lf.
[/one.lf/seven.lf] E. Ben-Sasson, “Zerocash, bitcoin, and transparent computational integrity,” Jan
/two.lf/zero.lf/one.lf/seven.lf.
[/one.lf/eight.lf] E. Ben-Sasson, A. Chiesa, D. Genkin, E. Tromer, and M. Virza, “SNARKs for C:
Verifying program executions succinctly and in zero knowledge,” in Advances in
Cryptology–CRYPTO /two.lf/zero.lf/one.lf/three.lf . Springer, /two.lf/zero.lf/one.lf/three.lf, pp. /nine.lf/zero.lf–/one.lf/zero.lf/eight.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/six.lf/four.lf/two.lf-
/four.lf/zero.lf/zero.lf/eight.lf/four.lf-/one.lf\_/six.lf.
[/one.lf/nine.lf] E. Ben-Sasson, A. Chiesa, M. Green, E. Tromer, and M. Virza, “Secure sampling of
public parameters for succinct zero knowledge proofs,” in /two.lf/zero.lf/one.lf/five.lf IEEE Symposium on
Security and Privacy (SP) . IEEE, /two.lf/zero.lf/one.lf/five.lf, pp. /two.lf/eight.lf/seven.lf–/three.lf/zero.lf/four.lf, doi:/one.lf/zero.lf./one.lf/one.lf/zero.lf/nine.lf/SP./two.lf/zero.lf/one.lf/five.lf./two.lf/five.lf.
[/two.lf/zero.lf] I. Bentov, A. Gabizon, and A. Mizrahi, “Cryptocurrencies without proof of work,” in
International Conference on Financial Cryptography and Data Security . Springer, /two.lf/zero.lf/one.lf/six.lf,
pp. /one.lf/four.lf/two.lf–/one.lf/five.lf/seven.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/six.lf/six.lf/two.lf-/five.lf/three.lf/three.lf/five.lf/seven.lf-/four.lf\_/one.lf/zero.lf.
[/two.lf/one.lf] K. Bhargavan, A. Delignat-Lavaud, C. Fournet, A. Gollamudi, G. Gonthier,
N. Kobeissi, N. Kulatova, A. Rastogi, T. Sibut-Pinote, N. Swamy, and S. Zanella-
Béguelin, “Formal veri/fi.ligacation of smart contracts: Short paper,” in Proceedings of the
/two.lf/zero.lf/one.lf/six.lf ACM Workshop on Programming Languages and Analysis for Security . ACM, /two.lf/zero.lf/one.lf/six.lf,
pp. /nine.lf/one.lf–/nine.lf/six.lf, doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//two.lf/nine.lf/nine.lf/three.lf/six.lf/zero.lf/zero.lf./two.lf/nine.lf/nine.lf/three.lf/six.lf/one.lf/one.lf.
[/two.lf/two.lf] P. Birnstill, S. Bretthauer, S. Greiner, and E. Krempel, “Privacy-preserving surveil-
lance: An interdisciplinary approach,” International Data Privacy Law , vol. /five.lf, no. /four.lf,
pp. /two.lf/nine.lf/eight.lf–/three.lf/zero.lf/eight.lf, /two.lf/zero.lf/one.lf/five.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/nine.lf/three.lf/idpl/ipv/zero.lf/two.lf/one.lf.
[/two.lf/three.lf] C. Blum and C. I. Zuber, “Liquid democracy: Potentials, problems, and per-
spectives,” Journal of Political Philosophy , vol. /two.lf/four.lf, no. /two.lf, pp. /one.lf/six.lf/two.lf–/one.lf/eight.lf/two.lf, /two.lf/zero.lf/one.lf/five.lf,
doi:/one.lf/zero.lf./one.lf/one.lf/one.lf/one.lf/jopp./one.lf/two.lf/zero.lf/six.lf/five.lf.
[/two.lf/four.lf] M. Blum, P. Feldman, and S. Micali, “Non-interactive zero-knowledge and its appli-
cations,” in Proceedings of the Twentieth Annual ACM Symposium on Theory of Computing .
/seven.lf/five.lf
ACM, /one.lf/nine.lf/eight.lf/eight.lf, pp. /one.lf/zero.lf/three.lf–/one.lf/one.lf/two.lf, doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//six.lf/two.lf/two.lf/one.lf/two.lf./six.lf/two.lf/two.lf/two.lf/two.lf.
[/two.lf/five.lf] D. Bogdanov, M. Jöemets, S. Siim, and M. Vaht, “How the Estonian tax and custom
board evaluated a tax fraud detection system based on secure multi-party compu-
tation,” in International Conference on Financial Cryptography and Data Security , /two.lf/zero.lf/one.lf/five.lf,
pp. /two.lf/two.lf/seven.lf–/two.lf/three.lf/four.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/six.lf/six.lf/two.lf-/four.lf/seven.lf/eight.lf/five.lf/four.lf-/seven.lf\_/one.lf/four.lf.
[/two.lf/six.lf] P. Bogetoft, D. L. Christensen, I. Damgård, M. Geisler, T. P. Jakobsen, M. Krøigaard,
J. D. Nielsen, J. B. Nielsen, K. Nielsen, J. Pagter, M. Schwartzbach, and T. Toft, “Se-
cure multiparty computation goes live,” in Financial Cryptography and Data Security .
Springer, /two.lf/zero.lf/zero.lf/nine.lf, pp. /three.lf/two.lf/five.lf–/three.lf/four.lf/three.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/six.lf/four.lf/two.lf-/zero.lf/three.lf/five.lf/four.lf/nine.lf-/four.lf\_/two.lf/zero.lf.
[/two.lf/seven.lf] D. Boneh, A. Sahai, and B. Waters, “Functional encryption: De/fi.liganitions and chal-
lenges,” in Theory of Cryptography . Springer, /two.lf/zero.lf/one.lf/one.lf, pp. /two.lf/five.lf/three.lf–/two.lf/seven.lf/three.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-
/six.lf/four.lf/two.lf-/one.lf/nine.lf/five.lf/seven.lf/one.lf-/six.lf\_/one.lf/six.lf.
[/two.lf/eight.lf] N. Bostrom, Superintelligence: Paths, dangers, strategies . Oxford: Oxford University
Press, /two.lf/zero.lf/one.lf/four.lf.
[/two.lf/nine.lf] N. Bostrom, A. Dafoe, and C. Flynn, “Policy desiderata
in the development of machine superintelligence.” [Online]. Avail-
able: https://www.fhi.ox.ac.uk/wp-content/uploads/Policy-Desiderata-in-the-
Development-of-Machine-Superintelligence.pdf
[/three.lf/zero.lf] K. Bradsher, “China blocks whatsapp, broadening online censorship,” The New York
Times , /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https://www.nytimes.com//two.lf/zero.lf/one.lf/seven.lf//zero.lf/nine.lf//two.lf/five.lf/business/
china-whatsapp-blocked.html
[/three.lf/one.lf] I. Braverman, “Passing the sni/f\_f.liga test: Police dogs as surveillance technology,”
Bu/f\_f.ligaalo Law Review , vol. /six.lf/one.lf, no. /one.lf, pp. /eight.lf/one.lf–/one.lf/six.lf/seven.lf, /two.lf/zero.lf/one.lf/three.lf. [Online]. Available:
https://digitalcommons.law.bu/f\_f.ligaalo.edu/journal\_articles//three.lf/three.lf/six.lf
[/three.lf/two.lf] M. Brundage, S. Avin et al. , “The malicious use of arti/fi.ligacial intelligence:
Forecasting, prevention, and mitigation,” /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https:
//maliciousaireport.com/
[/three.lf/three.lf] K. Buchholz, “How common is crypto?” Statista , /two.lf/zero.lf/two.lf/one.lf. [Online]. Available:
https://www.statista.com/chart//one.lf/eight.lf/three.lf/four.lf/five.lf/crypto-currency-adoption/
[/three.lf/four.lf] E. Buchman, “Tendermint: Byzantine fault tolerance in the age of blockchains,”
Master’s thesis, The University of Guelph, /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: http:
//hdl.handle.net//one.lf/zero.lf/two.lf/one.lf/four.lf//nine.lf/seven.lf/six.lf/nine.lf
[/three.lf/five.lf] R. Burn-Callander, “Skype inventor Jaan Tallinn wants to use Bit-
coin technology to save the world,” The Telegraph , Jun /two.lf/zero.lf/one.lf/six.lf. [Online].
Available: http://www.telegraph.co.uk/business//two.lf/zero.lf/one.lf/six.lf//zero.lf/six.lf//two.lf/zero.lf/skype-inventor-jaan-
tallinn-wants-to-use-bitcoin-technology-to-s/
/seven.lf/six.lf
[/three.lf/six.lf] V. Buterin, “DAOs, DACs, DAs and more: An incomplete terminology guide,”
Ethereum Blog, May /two.lf/zero.lf/one.lf/four.lf. [Online]. Available: https://blog.ethereum.org//two.lf/zero.lf/one.lf/four.lf//zero.lf/five.lf/
/zero.lf/six.lf/daos-dacs-das-and-more-an-incomplete-terminology-guide/
[/three.lf/seven.lf] ——, “An introduction to futarchy,” Aug /two.lf/zero.lf/one.lf/four.lf. [Online]. Available: https:
//blog.ethereum.org//two.lf/zero.lf/one.lf/four.lf//zero.lf/eight.lf//two.lf/one.lf/introduction-futarchy/
[/three.lf/eight.lf] ——, “Visions, part /one.lf: The value of blockchain technology,” Ethereum Blog,
Apr /two.lf/zero.lf/one.lf/five.lf. [Online]. Available: https://blog.ethereum.org//two.lf/zero.lf/one.lf/five.lf//zero.lf/four.lf//one.lf/three.lf/visions-part-
/one.lf-the-value-of-blockchain-technology/
[/three.lf/nine.lf] ——, “Visions, part /two.lf: The problem of trust,” Ethereum Blog, Apr /two.lf/zero.lf/one.lf/five.lf. [Online].
Available: https://blog.ethereum.org//two.lf/zero.lf/one.lf/five.lf//zero.lf/four.lf//two.lf/seven.lf/visions-part-/two.lf-the-problem-of-
trust/
[/four.lf/zero.lf] ——, “Why cryptoeconomics and x-risk researchers should
listen to each other more,” /two.lf/zero.lf/one.lf/six.lf. [Online]. Avail-
able: https://medium.com/@VitalikButerin/why-cryptoeconomics-and-x-risk-
researchers-should-listen-to-each-other-more-a/two.lfdb/seven.lf/two.lfb/three.lfe/eight.lf/six.lfb
[/four.lf/one.lf] ——, “Ethereum: A next-generation smart contract and
decentralized application platform,” /two.lf/zero.lf/one.lf/seven.lf. [Online]. Avail-
able: https://blockchainlab.com/pdf/Ethereum\_white\_paper-a\_next\_generation\_
smart\_contract\_and\_decentralized\_application\_platform-vitalik-buterin.pdf
[/four.lf/two.lf] M. Calabresi, “Iran nuclear deal: Veri/fi.ligacation is trickiest part,” Time , /two.lf/zero.lf/one.lf/five.lf. [Online].
Available: http://time.com//three.lf/nine.lf/four.lf/six.lf/eight.lf/six.lf/zero.lf/iran-nuclear-deal-inspections/
[/four.lf/three.lf] B. Caplan, “The logic of collective belief,” Rationality and Society , vol. /one.lf/five.lf, no. /two.lf, pp.
/two.lf/one.lf/eight.lf–/two.lf/four.lf/two.lf, /two.lf/zero.lf/zero.lf/three.lf, doi:/one.lf/zero.lf./one.lf/one.lf/seven.lf/seven.lf//one.lf/zero.lf/four.lf/three.lf/four.lf/six.lf/three.lf/one.lf/zero.lf/three.lf/zero.lf/one.lf/five.lf/zero.lf/zero.lf/two.lf/zero.lf/zero.lf/three.lf.
[/four.lf/four.lf] N. Cardozo, “The state of crypto law: /two.lf/zero.lf/one.lf/six.lf in review,” Electronic Frontier
Foundation, Jan /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https://www.e/f\_f.liga.org/deeplinks//two.lf/zero.lf/one.lf/six.lf//one.lf/two.lf/
crypto-state-law-end-/two.lf/zero.lf/one.lf/six.lf
[/four.lf/five.lf] H. Chen, W. Chung, J. Jie Xu, G. Wang, Y. Qin, and M. Chau, “Crime data mining:
A general framework and some examples,” Computer , vol. /three.lf/seven.lf, no. /four.lf, pp. /five.lf/zero.lf–/five.lf/six.lf, /two.lf/zero.lf/zero.lf/four.lf,
doi:/one.lf/zero.lf./one.lf/one.lf/zero.lf/nine.lf/MC./two.lf/zero.lf/zero.lf/four.lf./one.lf/two.lf/nine.lf/seven.lf/three.lf/zero.lf/one.lf.
[/four.lf/six.lf] U. W. Chohan, “Assessing the di/f\_f.ligaerences in bitcoin & other cryptocurrency le-
gality across national jurisdictions,” Critical Blockchain Research Initiative, /two.lf/zero.lf/one.lf/seven.lf,
/one.lf/zero.lf./two.lf/one.lf/three.lf/nine.lf/ssrn./three.lf/zero.lf/four.lf/two.lf/two.lf/four.lf/eight.lf.
[/four.lf/seven.lf] A. Choudhury, J. Loftus, E. Orsini, A. Patra, and N. P. Smart, “Between a rock and
a hard place: Interpolating between MPC and FHE,” in International Conference on
the Theory and Application of Cryptology and Information Security . Springer, /two.lf/zero.lf/one.lf/three.lf, pp.
/two.lf/two.lf/one.lf–/two.lf/four.lf/zero.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/six.lf/four.lf/two.lf-/four.lf/two.lf/zero.lf/four.lf/five.lf-/zero.lf\_/one.lf/two.lf.
/seven.lf/seven.lf
[/four.lf/eight.lf] K. Christidis and M. Devetsikiotis, “Blockchains and smart contracts
for the internet of things,” IEEE Access , vol. /four.lf, pp. /two.lf/two.lf/nine.lf/two.lf–/two.lf/three.lf/zero.lf/three.lf, /two.lf/zero.lf/one.lf/six.lf,
doi:/one.lf/zero.lf./one.lf/one.lf/zero.lf/nine.lf/ACCESS./two.lf/zero.lf/one.lf/six.lf./two.lf/five.lf/six.lf/six.lf/three.lf/three.lf/nine.lf.
[/four.lf/nine.lf] J. S. Chung, A. Jamaludin, and A. Zisserman, “You said that?” /two.lf/zero.lf/one.lf/seven.lf, arXiv preprint
arXiv:/one.lf/seven.lf/zero.lf/five.lf./zero.lf/two.lf/nine.lf/six.lf/six.lf. [Online]. Available: https://arxiv.org/abs//one.lf/seven.lf/zero.lf/five.lf./zero.lf/two.lf/nine.lf/six.lf/six.lf
[/five.lf/zero.lf] M. C. Clutter, “Dogs, drones, and defendants: The fourth amendment in the digital
age,” George Mason Law Review , vol. /two.lf/one.lf, pp. /five.lf/five.lf/seven.lf–/five.lf/seven.lf/one.lf, /two.lf/zero.lf/one.lf/three.lf.
[/five.lf/one.lf] J. B. Comey, “Going dark: Are technology, privacy, and public safety on
a collision course?” Speech, Federal Bureau of Investigation, /two.lf/zero.lf/one.lf/four.lf. [Online].
Available: https://www./f\_b.ligai.gov/news/speeches/going-dark-are-technology-privacy-
and-public-safety-on-a-collision-course
[/five.lf/two.lf] C. Comley, M. Comley, P. Eggins, G. George, S. Holloway, M. Ley, P. Thompson,
and K. Warburton, “Con/fi.ligadence, security and veri/fi.ligacation: The challenge of
global nuclear weapons arms control,” Atomic Weapons Establishment, Tech. Rep.
AWE/TR//two.lf/zero.lf/zero.lf/zero.lf//zero.lf/zero.lf/one.lf, /two.lf/zero.lf/zero.lf/zero.lf. [Online]. Available: http:///fi.ligassilematerials.org/library/
awe/zero.lf/zero.lf.pdf
[/five.lf/three.lf] R. Cramer, R. Gennaro, and B. Schoenmakers, “A secure and optimally e/f\_f\_i.ligacient
multi-authority election scheme,” European Transactions on Telecommunications , vol. /eight.lf,
no. /five.lf, pp. /four.lf/eight.lf/one.lf–/four.lf/nine.lf/zero.lf, /one.lf/nine.lf/nine.lf/seven.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/two.lf/ett./four.lf/four.lf/six.lf/zero.lf/zero.lf/eight.lf/zero.lf/five.lf/zero.lf/six.lf.
[/five.lf/four.lf] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Sax-
ena, E. Shi, E. G. Sirer, D. Song, and R. Wattenhofer, “On scaling decentralized
blockchains,” in International Conference on Financial Cryptography and Data Security .
Springer, /two.lf/zero.lf/one.lf/six.lf, pp. /one.lf/zero.lf/six.lf–/one.lf/two.lf/five.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/six.lf/six.lf/two.lf-/five.lf/three.lf/three.lf/five.lf/seven.lf-/four.lf\_/eight.lf.
[/five.lf/five.lf] S. A. Crosby and D. S. Wallach, “E/f\_f\_i.ligacient data structures for tamper-evident
logging,” in USENIX Security Symposium , /two.lf/zero.lf/zero.lf/nine.lf, pp. /three.lf/one.lf/seven.lf–/three.lf/three.lf/four.lf. [Online]. Available:
https://www.usenix.org/legacy/event/sec/zero.lf/nine.lf/tech/full\_papers/crosby.pdf
[/five.lf/six.lf] S. Davidson, P. De Filippi, and J. Potts, “Economics of blockchain,” /two.lf/zero.lf/one.lf/six.lf,
doi:/one.lf/zero.lf./two.lf/one.lf/three.lf/nine.lf/ssrn./two.lf/seven.lf/four.lf/four.lf/seven.lf/five.lf/one.lf.
[/five.lf/seven.lf] W. Di/f\_f\_i.ligae and M. Hellman, “New directions in cryptography,” IEEE Transactions on
Information Theory , vol. /two.lf/two.lf, no. /six.lf, pp. /six.lf/four.lf/four.lf–/six.lf/five.lf/four.lf, /one.lf/nine.lf/seven.lf/six.lf, doi:/one.lf/zero.lf./one.lf/one.lf/zero.lf/nine.lf/TIT./one.lf/nine.lf/seven.lf/six.lf./one.lf/zero.lf/five.lf/five.lf/six.lf/three.lf/eight.lf.
[/five.lf/eight.lf] G. Eder, “Digital transformation: Blockchain and land titles,” in /two.lf/zero.lf/one.lf/nine.lf
OECD Global Anti-Corruption & Integrity Forum , /two.lf/zero.lf/one.lf/nine.lf. [Online]. Avail-
able: https://www.oecd.org/corruption/integrity-forum/academic-papers/Georg%
/two.lf/zero.lfEder-%/two.lf/zero.lfBlockchain%/two.lf/zero.lf-%/two.lf/zero.lfGhana\_veri/fi.ligaed.pdf
[/five.lf/nine.lf] K. Ermoshina, F. Musiani, and H. Halpin, “End-to-end encrypted messaging proto-
cols: An overview,” in International Conference on Internet Science . Springer, /two.lf/zero.lf/one.lf/six.lf,
/seven.lf/eight.lf
pp. /two.lf/four.lf/four.lf–/two.lf/five.lf/four.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/three.lf/one.lf/nine.lf-/four.lf/five.lf/nine.lf/eight.lf/two.lf-/zero.lf\_/two.lf/two.lf.
[/six.lf/zero.lf] “Sharding FAQ,” Ethereum Wiki, /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https://eth.wiki/
sharding/Sharding-FAQs
[/six.lf/one.lf] “Decentralized /fi.liganance (DeFi),” Ethereum.org, /two.lf/zero.lf/two.lf/one.lf. [Online]. Available: https:
//ethereum.org/en/de/fi.liga/
[/six.lf/two.lf] “Layer /two.lf scaling,” Ethereum.org, /two.lf/zero.lf/two.lf/one.lf. [Online]. Available: https://ethereum.org/
nb/developers/docs/layer-/two.lf-scaling/
[/six.lf/three.lf] “Non-fungible tokens (NFT),” Ethereum.org, /two.lf/zero.lf/two.lf/one.lf. [Online]. Available: https:
//ethereum.org/en/nft/
[/six.lf/four.lf] I. Eyal and E. G. Sirer, “Majority is not enough: Bitcoin mining is vulnerable,” in
International Conference on Financial Cryptography and Data Security . Springer, /two.lf/zero.lf/one.lf/four.lf,
pp. /four.lf/three.lf/six.lf–/four.lf/five.lf/four.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/six.lf/six.lf/two.lf-/four.lf/five.lf/four.lf/seven.lf/two.lf-/five.lf\_/two.lf/eight.lf.
[/six.lf/five.lf] J. D. Fearon, “Rationalist explanations for war,” International organization , vol. /four.lf/nine.lf,
no. /three.lf, pp. /three.lf/seven.lf/nine.lf–/four.lf/one.lf/four.lf, /one.lf/nine.lf/nine.lf/five.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/one.lf/seven.lf/S/zero.lf/zero.lf/two.lf/zero.lf/eight.lf/one.lf/eight.lf/three.lf/zero.lf/zero.lf/zero.lf/three.lf/three.lf/three.lf/two.lf/four.lf.
[/six.lf/six.lf] J. Feigenbaum and B. Ford, “Multiple objectives of lawful-surveillance protocols,” in
Cambridge International Workshop on Security Protocols , /two.lf/zero.lf/one.lf/seven.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/three.lf/one.lf/nine.lf-
/seven.lf/one.lf/zero.lf/seven.lf/five.lf-/four.lf\_/one.lf.
[/six.lf/seven.lf] K. Finley, “A /dollar.lf/five.lf/zero.lf million hack just showed that the DAO was all too human,”
Wired , Jun /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: https://www.wired.com//two.lf/zero.lf/one.lf/six.lf//zero.lf/six.lf//five.lf/zero.lf-million-
hack-just-showed-dao-human/
[/six.lf/eight.lf] B. Fisch, D. Freund, and M. Naor, “Physical zero-knowledge proofs of physical prop-
erties,” in Advances in Crypotology–CRYPTO /two.lf/zero.lf/one.lf/four.lf . Springer, /two.lf/zero.lf/one.lf/four.lf, pp. /three.lf/one.lf/three.lf–/three.lf/three.lf/six.lf,
doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/six.lf/six.lf/two.lf-/four.lf/four.lf/three.lf/eight.lf/one.lf-/one.lf\_/one.lf/eight.lf.
[/six.lf/nine.lf] K. B. Frikken and M. J. Atallah, “Privacy preserving electronic surveillance,” in Pro-
ceedings of the /two.lf/zero.lf/zero.lf/three.lf ACM workshop on Privacy in the Electronic Society . ACM, /two.lf/zero.lf/zero.lf/three.lf,
pp. /four.lf/five.lf–/five.lf/two.lf, doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//one.lf/zero.lf/zero.lf/five.lf/one.lf/four.lf/zero.lf./one.lf/zero.lf/zero.lf/five.lf/one.lf/four.lf/eight.lf.
[/seven.lf/zero.lf] U. Gasser, N. Gertner, J. L. Goldsmith, S. Landau, J. S. Nye, D. O’Brien,
M. G. Olsen, D. Renan, J. Sanchez, B. Schneider, L. Schwartzol, and J. L.
Zittrain, “Don’t panic: Making progress on the “going dark” debate,” Berkman
Center for Internet & Society at Harvard Law School, /two.lf/zero.lf/one.lf/six.lf. [Online]. Available:
http://nrs.harvard.edu/urn-/three.lf:HUL.InstRepos:/two.lf/eight.lf/five.lf/five.lf/two.lf/five.lf/seven.lf/six.lf
[/seven.lf/one.lf] M. Genesereth, “Computational law: The cop in the backseat,” CodeX: The
Center for Legal Informatics, Stanford University, /two.lf/zero.lf/one.lf/five.lf. [Online]. Available:
http://logic.stanford.edu/publications/genesereth/complaw.pdf
[/seven.lf/two.lf] C. Gentry, “Fully homomorphic encryption using ideal lattices,” in Proceedings of
/seven.lf/nine.lf
the Forty-First Annual ACM symposium on Theory of Computing , /two.lf/zero.lf/zero.lf/nine.lf, pp. /one.lf/six.lf/nine.lf–/one.lf/seven.lf/eight.lf,
doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//one.lf/five.lf/three.lf/six.lf/four.lf/one.lf/four.lf./one.lf/five.lf/three.lf/six.lf/four.lf/four.lf/zero.lf.
[/seven.lf/three.lf] A. Gerber and P. C. Wichardt, “Providing public goods in the absence of strong
institutions,” Journal of Public Economics , vol. /nine.lf/three.lf, no. /three.lf-/four.lf, pp. /four.lf/two.lf/nine.lf–/four.lf/three.lf/nine.lf, /two.lf/zero.lf/zero.lf/nine.lf,
doi:/one.lf/zero.lf./one.lf/zero.lf/one.lf/six.lf/j.jpubeco./two.lf/zero.lf/zero.lf/eight.lf./one.lf/zero.lf./zero.lf/zero.lf/six.lf.
[/seven.lf/four.lf] D. Ghupta, “Practical and deployable secure multi-party computation,” Ph.D.
dissertation, Yale University, /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: https://www.cs.yale.edu/
homes/jf/Debayan-thesis.pdf
[/seven.lf/five.lf] S. Gibbs, “EU seeks to outlaw ’backdoors’ in new data pri-
vacy proposals,” The Guardian , Jun /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available:
https://www.theguardian.com/technology//two.lf/zero.lf/one.lf/seven.lf/jun//one.lf/nine.lf/eu-outlaw-backdoors-new-
data-privacy-proposals-uk-government-encrypted-communications-whatsapp
[/seven.lf/six.lf] A. Glaser, B. Barak, and R. J. Goldston, “A zero-knowledge protocol for nu-
clear warhead veri/fi.ligacation,” Nature , vol. /five.lf/one.lf/zero.lf, no. /seven.lf/five.lf/zero.lf/six.lf, pp. /four.lf/nine.lf/seven.lf–/five.lf/zero.lf/two.lf, /two.lf/zero.lf/one.lf/four.lf,
doi:/one.lf/zero.lf./one.lf/zero.lf/three.lf/eight.lf/nature/one.lf/three.lf/four.lf/five.lf/seven.lf.
[/seven.lf/seven.lf] E. Goldberg, “Getting beyond intuition in the probable cause inquiry,” Lewis
& Clark Law Review , vol. /one.lf/seven.lf, no. /three.lf, pp. /seven.lf/eight.lf/nine.lf–/eight.lf/three.lf/eight.lf, /two.lf/zero.lf/one.lf/three.lf. [Online]. Available:
https://law.lclark.edu/live//fi.ligales//one.lf/five.lf/three.lf/two.lf/two.lf-lcb/one.lf/seven.lf/three.lfart/three.lfgoldbergpdf
[/seven.lf/eight.lf] S. Goldwasser, Y. Kalai, R. A. Popa, V. Vaikuntanathan, and N. Zeldovich, “Reusable
garbled circuits and succinct functional encryption,” in Proceedings of the Forty-
Fifth Annual ACM Symposium on Theory of Computing . ACM, /two.lf/zero.lf/one.lf/three.lf, pp. /five.lf/five.lf/five.lf–/five.lf/six.lf/four.lf,
doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//two.lf/four.lf/eight.lf/eight.lf/six.lf/zero.lf/eight.lf./two.lf/four.lf/eight.lf/eight.lf/six.lf/seven.lf/eight.lf.
[/seven.lf/nine.lf] S. Goldwasser, Y. T. Kalai, R. A. Popa, V. Vaikuntanathan, and N. Zeldovich, “How
to run Turing machines on encrypted data,” in Advances in Cryptology–CRYPTO /two.lf/zero.lf/one.lf/three.lf .
Springer-Verlag, /two.lf/zero.lf/one.lf/three.lf, pp. /five.lf/three.lf/six.lf–/five.lf/five.lf/three.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/three.lf-/six.lf/four.lf/two.lf-/four.lf/zero.lf/zero.lf/eight.lf/four.lf-/one.lf\_/three.lf/zero.lf.
[/eight.lf/zero.lf] S. Goldwasser, S. Micali, and C. Racko/f\_f.liga, “The knowledge complexity of interac-
tive proof systems,” SIAM Journal on Computing , vol. /one.lf/eight.lf, no. /one.lf, pp. /one.lf/eight.lf/six.lf–/two.lf/zero.lf/eight.lf, /one.lf/nine.lf/eight.lf/nine.lf,
doi:/one.lf/zero.lf./one.lf/one.lf/three.lf/seven.lf//zero.lf/two.lf/one.lf/eight.lf/zero.lf/one.lf/two.lf.
[/eight.lf/one.lf] H. R. Gow, D. H. Streeter, and J. F. Swinnen, “How private contract enforcement
mechanisms can succeed where public institutions,” Agricultural Economics , vol. /two.lf/three.lf,
no. /three.lf, pp. /two.lf/five.lf/three.lf–/two.lf/six.lf/five.lf, /two.lf/zero.lf/zero.lf/zero.lf, doi:/one.lf/zero.lf./one.lf/one.lf/one.lf/one.lf/j./one.lf/five.lf/seven.lf/four.lf-/zero.lf/eight.lf/six.lf/two.lf./two.lf/zero.lf/zero.lf/zero.lf.tb/zero.lf/zero.lf/two.lf/seven.lf/seven.lf.x.
[/eight.lf/two.lf] K. Grace, J. Salvatier, A. Dafoe, B. Zhang, and O. Evans, “When will AI exceed
human performance? Evidence from AI experts,” arXiv preprint arXiv:/one.lf/seven.lf/zero.lf/five.lf./zero.lf/eight.lf/eight.lf/zero.lf/seven.lf,
/two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https://arxiv.org/abs//one.lf/seven.lf/zero.lf/five.lf./zero.lf/eight.lf/eight.lf/zero.lf/seven.lf
[/eight.lf/three.lf] A. Greenberg, “Zcash, an untraceable bitcoin alternative, launches in alpha,”
Wired , Jun /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https://www.wired.com//two.lf/zero.lf/one.lf/six.lf//zero.lf/one.lf/zcash-an-
/eight.lf/zero.lf
untraceable-bitcoin-alternative-launches-in-alpha/
[/eight.lf/four.lf] S. Haber and W. S. Stornetta, “How to time-stamp a digital document,” in Ad-
vances in Cryptology–CRYPTO /one.lf/nine.lf/nine.lf/zero.lf . Springer, /one.lf/nine.lf/nine.lf/zero.lf, pp. /four.lf/three.lf/seven.lf–/four.lf/five.lf/five.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//three.lf-
/five.lf/four.lf/zero.lf-/three.lf/eight.lf/four.lf/two.lf/four.lf-/three.lf\_/three.lf/two.lf.
[/eight.lf/five.lf] B. H. Hall and B. Khan, “Adoption of new technology,” Working Paper /nine.lf/seven.lf/three.lf/zero.lf, Na-
tional Bureau of Economic Research, /two.lf/zero.lf/zero.lf/three.lf, doi:/one.lf/zero.lf./three.lf/three.lf/eight.lf/six.lf/w/nine.lf/seven.lf/three.lf/zero.lf.
[/eight.lf/six.lf] R. Hanson, “Shall we vote on values, but bet on beliefs?” Journal of Political Philosophy ,
vol. /two.lf/one.lf, pp. /one.lf/five.lf/one.lf–/one.lf/seven.lf/eight.lf, /two.lf/zero.lf/zero.lf/three.lf, doi:/one.lf/zero.lf./one.lf/one.lf/one.lf/one.lf/jopp./one.lf/two.lf/zero.lf/zero.lf/eight.lf.
[/eight.lf/seven.lf] G. Hardin, “The tragedy of the commons,” Journal of Natural Resources Policy Research ,
vol. /one.lf, no. /three.lf, pp. /two.lf/four.lf/three.lf–/two.lf/five.lf/three.lf, /two.lf/zero.lf/zero.lf/nine.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/eight.lf/zero.lf//one.lf/nine.lf/three.lf/nine.lf/zero.lf/four.lf/five.lf/zero.lf/nine.lf/zero.lf/three.lf/zero.lf/three.lf/seven.lf/three.lf/zero.lf/two.lf.
[/eight.lf/eight.lf] M. Harrington, “Survey: People’s trust has declined in business, media, government,
and NGOs,” Jan /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https://hbr.org//two.lf/zero.lf/one.lf/seven.lf//zero.lf/one.lf/survey-peoples-
trust-has-declined-in-business-media-government-and-ngos
[/eight.lf/nine.lf] O. D. Hart, “Incomplete contracts and the theory of the /fi.ligarm,” Jour-
nal of Law, Economics, & Organization , vol. /four.lf, no. /one.lf, pp. /one.lf/one.lf/nine.lf–/one.lf/three.lf/nine.lf, /one.lf/nine.lf/eight.lf/eight.lf,
doi:/one.lf/zero.lf./one.lf/zero.lf/nine.lf/three.lf/oxfordjournals.jleo.a/zero.lf/three.lf/six.lf/nine.lf/four.lf/zero.lf.
[/nine.lf/zero.lf] A. Hern, “Revolv devices bricked as Google’s Nest shuts down smart home
company,” The Guardian , Apr /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: https://www.theguardian.
com/technology//two.lf/zero.lf/one.lf/six.lf/apr//zero.lf/five.lf/revolv-devices-bricked-google-nest-smart-home
[/nine.lf/one.lf] ——, “Google’s DeepMind plans bitcoin-style health record track-
ing for hospitals,” The Guardian , Mar /two.lf/zero.lf/one.lf/seven.lf. [Online]. Avail-
able: https://www.theguardian.com/technology//two.lf/zero.lf/one.lf/seven.lf/mar//zero.lf/nine.lf/google-deepmind-
health-records-tracking-blockchain-nhs-hospitals
[/nine.lf/two.lf] ——, “UK government can force encryption removal, but fears
losing, experts say,” The Guardian , Mar /two.lf/zero.lf/one.lf/seven.lf. [Online]. Avail-
able: https://www.theguardian.com/technology//two.lf/zero.lf/one.lf/seven.lf/mar//two.lf/nine.lf/uk-government-
encryption-whatsapp-investigatory-powers-act
[/nine.lf/three.lf] R. Higgott, “International political institutions,” in The Oxford handbook of Political
Institutions , S. A. Binder, R. A. W. Rhodes, and B. A. Rockman, Eds. Oxford: Oxford
University Press, /two.lf/zero.lf/zero.lf/six.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/nine.lf/three.lf/oxfordhb//nine.lf/seven.lf/eight.lf/zero.lf/one.lf/nine.lf/nine.lf/five.lf/four.lf/eight.lf/four.lf/six.lf/zero.lf./zero.lf/zero.lf/three.lf./zero.lf/zero.lf/three.lf/one.lf.
[/nine.lf/four.lf] F. H. Hinsley, “The in/fl.ligauence of ULTRA in the Second World War,” Seminar
Transcript, /one.lf/nine.lf/nine.lf/three.lf. [Online]. Available: http://www.cdpa.co.uk/UoP/HoC/Lectures/
HoC\_/zero.lf/eight.lfe.PDF
[/nine.lf/five.lf] J. Hovi, M. Greaker, C. Hagem, and B. Holtsmark, “A credible compliance enforce-
ment system for the climate regime,” Climate Policy , vol. /one.lf/two.lf, no. /six.lf, pp. /seven.lf/four.lf/one.lf–/seven.lf/five.lf/four.lf, /two.lf/zero.lf/one.lf/two.lf,
doi:/one.lf/zero.lf./one.lf/zero.lf/eight.lf/zero.lf//one.lf/four.lf/six.lf/nine.lf/three.lf/zero.lf/six.lf/two.lf./two.lf/zero.lf/one.lf/two.lf./six.lf/nine.lf/two.lf/two.lf/zero.lf/six.lf.
/eight.lf/one.lf
[/nine.lf/six.lf] A. Irrera and J. Kelly, “Blockchain could save investment banks up to
/dollar.lf/one.lf/two.lf billion a year: Accenture,” Reuters , Jan /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available:
http://uk.reuters.com/article/us-banks-blockchain-accenture/blockchain-could-
save-investment-banks-up-to-/one.lf/two.lf-billion-a-year-accenture-idUKKBN/one.lf/five.lf/one.lf/one.lfOU
[/nine.lf/seven.lf] ITU-T, “Distributed ledger technologies and /fi.liganancial inclusion,” Focus
Group Technical Report, International Telecommunications Union, /two.lf/zero.lf/one.lf/seven.lf.
[Online]. Available: https://www.itu.int/en/ITU-T/focusgroups/dfs/Documents/
/two.lf/zero.lf/one.lf/seven.lf/zero.lf/three.lf/ITU\_FGDFS\_Report-on-DLT-and-Financial-Inclusion.pdf
[/nine.lf/eight.lf] A. Juels, A. Kosba, and E. Shi, “The Ring of Gyges: Investigating the fu-
ture of criminal smart contracts,” in Proceedings of the /two.lf/zero.lf/one.lf/six.lf ACM SIGSAC Con-
ference on Computer and Communications Security . ACM, /two.lf/zero.lf/one.lf/six.lf, pp. /two.lf/eight.lf/three.lf–/two.lf/nine.lf/five.lf,
doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//two.lf/nine.lf/seven.lf/six.lf/seven.lf/four.lf/nine.lf./two.lf/nine.lf/seven.lf/eight.lf/three.lf/six.lf/two.lf.
[/nine.lf/nine.lf] J. Katz and Y. Lindell, Introduction to Modern Cryptography . Boca Raton, FL: CRC
Press, /two.lf/zero.lf/one.lf/four.lf.
[/one.lf/zero.lf/zero.lf] B. Kellman, D. S. Gualtieri, and E. A. Tanzman, “Disarmament and disclosure: How
arms control veri/fi.ligacation can proceed without threatening con/fi.ligadential business in-
formation,” Harvard International Law Journal , vol. /three.lf/six.lf, pp. /seven.lf/one.lf–/one.lf/two.lf/six.lf, /one.lf/nine.lf/nine.lf/five.lf.
[/one.lf/zero.lf/one.lf] L. Kello, The Virtual Weapon and International Order . New Haven, CT: Yale University
Press, /two.lf/zero.lf/one.lf/seven.lf.
[/one.lf/zero.lf/two.lf] T. I. Kiviat, “Beyond bitcoin: Issues in regulating blockchain tranactions,” Duke LJ ,
vol. /six.lf/five.lf, pp. /five.lf/six.lf/nine.lf–/six.lf/zero.lf/eight.lf, /two.lf/zero.lf/one.lf/five.lf. [Online]. Available: https://scholarship.law.duke.edu/
dlj/vol/six.lf/five.lf/iss/three.lf//four.lf/
[/one.lf/zero.lf/three.lf] J. A. Kroll, J. Huey, S. Barocas, E. W. Felten, J. R. Reidenberg, D. G.
Robinson, and H. Yu, “Accountable algorithms,” University of Pennsylvania
Law Review , vol. /one.lf/six.lf/five.lf, no. /three.lf, pp. /six.lf/three.lf/three.lf–/seven.lf/zero.lf/five.lf, /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: https:
//www.pennlawreview.com//two.lf/zero.lf/one.lf/seven.lf//zero.lf/two.lf//two.lf/three.lf/accountable-algorithms/
[/one.lf/zero.lf/four.lf] E. Kuo, B. Iles, and M. R. Cruz, “Ampleforth: A new synthetic commodity,”
Ampleforth, Tech. Rep., /two.lf/zero.lf/one.lf/eight.lf. [Online]. Available: https://www.ampleforth.org/
papers/
[/one.lf/zero.lf/five.lf] L. Lessig, Code and Other Laws of Cyberspace . New York: Basic Books, /one.lf/nine.lf/nine.lf/nine.lf.
[/one.lf/zero.lf/six.lf] M. C. Libicki, Cyberdeterrence and Cyberwar . Santa Monica, CA: Rand Corporation,
/two.lf/zero.lf/zero.lf/nine.lf. [Online]. Available: https://www.rand.org/pubs/monographs/MG/eight.lf/seven.lf/seven.lf.html
[/one.lf/zero.lf/seven.lf] “White paper,” Libra Association, /two.lf/zero.lf/one.lf/nine.lf. [Online]. Available: https://www.diem.
com/en-us/white-paper/
[/one.lf/zero.lf/eight.lf] Y. Lindell and B. Pinkas, “Secure multiparty computation for privacy-preserving
data mining,” Journal of Privacy and Conﬁdentiality , vol. /one.lf, no. /one.lf, pp. /five.lf/nine.lf–/nine.lf/eight.lf, /two.lf/zero.lf/zero.lf/nine.lf,
/eight.lf/two.lf
doi:/one.lf/zero.lf./two.lf/nine.lf/zero.lf/one.lf/two.lf/jpc.v/one.lfi/one.lf./five.lf/six.lf/six.lf.
[/one.lf/zero.lf/nine.lf] C. A. Mack, “Fifty years of Moore’s Law,” IEEE Transactions on Semiconductor Manu-
facturing , vol. /two.lf/four.lf, no. /two.lf, pp. /two.lf/zero.lf/two.lf–/two.lf/zero.lf/seven.lf, /two.lf/zero.lf/one.lf/one.lf, doi:/one.lf/zero.lf./one.lf/one.lf/zero.lf/nine.lf/TSM./two.lf/zero.lf/one.lf/zero.lf./two.lf/zero.lf/nine.lf/six.lf/four.lf/three.lf/seven.lf.
[/one.lf/one.lf/zero.lf] A. Martin and I. Martinovic, “Security and privacy impacts of a unique
personal identi/fi.ligaer,” University of Oxford Cyber Studies Programme, /two.lf/zero.lf/one.lf/six.lf.
[Online]. Available: https://ora.ox.ac.uk/objects/uuid:/nine.lf/zero.lfcf/one.lf/four.lfa/one.lf-beb/three.lf-/four.lf/three.lf/two.lf/two.lf-b/one.lf/eight.lfd-
de/f\_f.ligae/eight.lfc/seven.lff/eight.lf/six.lf/one.lf
[/one.lf/one.lf/one.lf] J. Matonis, “WikiLeaks bypasses /fi.liganancial blockade with bitcoin,” Aug /two.lf/zero.lf/one.lf/two.lf. [On-
line]. Available: https://www.forbes.com/sites/jonmatonis//two.lf/zero.lf/one.lf/two.lf//zero.lf/eight.lf//two.lf/zero.lf/wikileaks-
bypasses-/fi.liganancial-blockade-with-bitcoin
[/one.lf/one.lf/two.lf] D. M. McEvoy, “Enforcing compliance with international environmental agreements
using a deposit-refund system,” International Environmental Agreements: Politics, Law
and Economics , vol. /one.lf/three.lf, no. /four.lf, pp. /four.lf/eight.lf/one.lf–/four.lf/nine.lf/six.lf, /two.lf/zero.lf/one.lf/three.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf/s/one.lf/zero.lf/seven.lf/eight.lf/four.lf-/zero.lf/one.lf/three.lf-/nine.lf/two.lf/zero.lf/nine.lf-/two.lf.
[/one.lf/one.lf/three.lf] R. Merkle, “DAOs, democracy and governance,” Cryonics Magazine , vol. /three.lf/seven.lf, no. /four.lf, pp.
/two.lf/eight.lf–/four.lf/zero.lf, /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: https://www.alcor.org/docs/cryonics-magazine-
/two.lf/zero.lf/one.lf/six.lf-/zero.lf/four.lf.pdf#page=/two.lf/eight.lf
[/one.lf/one.lf/four.lf] R. C. Merkle, “Secrecy, authentication, and public key systems,” Information Sys-
tems Laboratory, Stanford University, Tech. Rep., /one.lf/nine.lf/seven.lf/nine.lf.
[/one.lf/one.lf/five.lf] M. Minzner, “Putting probability back into probable cause,” Texas Law Review ,
vol. /eight.lf/seven.lf, no. /five.lf, pp. /nine.lf/one.lf/three.lf–/nine.lf/six.lf/two.lf, /two.lf/zero.lf/zero.lf/nine.lf. [Online]. Available: https://digitalrepository.unm.
edu/law\_facultyscholarship//four.lf/seven.lf/eight.lf/
[/one.lf/one.lf/six.lf] M. Möser, K. Soska, E. Heilman, H. Lee, Kevin He/f\_f.ligaan, S. Srivastava, K. Hogan,
J. Hennessey, A. Miller, A. Narayanan, and N. Christin, “An empirical analysis
of linkability in the Monero blockchain,” arXiv preprint arXiv:/one.lf/seven.lf/zero.lf/four.lf./zero.lf/four.lf/two.lf/nine.lf/nine.lf, /two.lf/zero.lf/one.lf/seven.lf.
[Online]. Available: https://arxiv.org/abs//one.lf/seven.lf/zero.lf/four.lf./zero.lf/four.lf/two.lf/nine.lf/nine.lf
[/one.lf/one.lf/seven.lf] M. Naehrig, K. Lauter, and V. Vaikuntanathan, “Can homomorphic encryption be
practical?” in Proceedings of the /three.lfrd ACM workshop on Cloud Computing Security Work-
shop. ACM, /two.lf/zero.lf/one.lf/one.lf, pp. /one.lf/one.lf/three.lf–/one.lf/two.lf/four.lf, doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//two.lf/zero.lf/four.lf/six.lf/six.lf/six.lf/zero.lf./two.lf/zero.lf/four.lf/six.lf/six.lf/eight.lf/two.lf.
[/one.lf/one.lf/eight.lf] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” /two.lf/zero.lf/zero.lf/eight.lf.
[/one.lf/one.lf/nine.lf] A. Narayanan, J. Bonneau, E. Felten, A. Miller, and S. Goldfeder, Bitcoin and Crypto-
currency Technologies: A Comprehensive Introduction . Princeton, NJ: Princeton Uni-
versity Press, /two.lf/zero.lf/one.lf/six.lf.
[/one.lf/two.lf/zero.lf] D. Nguyen, “Venezuela’s bitcoin story puts it in a category of one,” NASDAQ,
/two.lf/zero.lf/two.lf/zero.lf. [Online]. Available: https://www.nasdaq.com/articles/venezuelas-bitcoin-
story-puts-it-in-a-category-of-one-/two.lf/zero.lf/two.lf/zero.lf-/one.lf/one.lf-/one.lf/one.lf
/eight.lf/three.lf
[/one.lf/two.lf/one.lf] J. Nielsen, “Nielsens law of internet bandwidth,” Nielsen Norman Group, /one.lf/nine.lf/nine.lf/eight.lf.
[Online]. Available: https://www.nngroup.com/articles/law-of-bandwidth/
[/one.lf/two.lf/two.lf] D. C. North, “Institutions, transaction costs and economic growth,” Economic In-
quiry , vol. /two.lf/five.lf, no. /three.lf, pp. /four.lf/one.lf/nine.lf–/four.lf/two.lf/eight.lf, /one.lf/nine.lf/eight.lf/seven.lf, doi:/one.lf/zero.lf./one.lf/one.lf/one.lf/one.lf/j./one.lf/four.lf/six.lf/five.lf-/seven.lf/two.lf/nine.lf/five.lf./one.lf/nine.lf/eight.lf/seven.lf.tb/zero.lf/zero.lf/seven.lf/five.lf/zero.lf.x.
[/one.lf/two.lf/three.lf] M. Olson, The logic of collective action: Public Goods and the Theory of Groups . Cam-
bridge, MA: Harvard University Press, /two.lf/zero.lf/zero.lf/nine.lf.
[/one.lf/two.lf/four.lf] A. O’Neill, “De/fi.liganitional issues in functional encryption,” IACR Cryptology
ePrint Archive, Report /two.lf/zero.lf/one.lf/zero.lf//five.lf/five.lf/six.lf, p. /five.lf/five.lf/six.lf, /two.lf/zero.lf/one.lf/zero.lf. [Online]. Available: https:
//eprint.iacr.org//two.lf/zero.lf/one.lf/zero.lf//five.lf/five.lf/six.lf
[/one.lf/two.lf/five.lf] P. O’Neill, Veriﬁcation in an Age of Insecurity: The Future of Arms Control Compliance .
Oxford: Oxford University Press, /two.lf/zero.lf/zero.lf/nine.lf.
[/one.lf/two.lf/six.lf] OpenMined, “Openmined welcome package,” GitHub, /two.lf/zero.lf/two.lf/one.lf. [Online]. Available:
https://github.com/OpenMined/OM-Welcome-Package
[/one.lf/two.lf/seven.lf] E. Ortiz-Ospina and M. Roser, “Trust,” Our World in Data. [Online]. Available:
https://ourworldindata.org/trust
[/one.lf/two.lf/eight.lf] E. Ostrom, J. Burger, C. B. Field, R. B. Norgaard, and D. Policansky, “Revisiting the
commons: Local lessons, global challenges,” Science , vol. /two.lf/eight.lf/four.lf, no. /five.lf/four.lf/one.lf/two.lf, pp. /two.lf/seven.lf/eight.lf–/two.lf/eight.lf/two.lf,
/one.lf/nine.lf/nine.lf/nine.lf, doi:/one.lf/zero.lf./one.lf/one.lf/two.lf/six.lf/science./two.lf/eight.lf/four.lf./five.lf/four.lf/one.lf/two.lf./two.lf/seven.lf/eight.lf.
[/one.lf/two.lf/nine.lf] A. Pasternack, “Police body cameras will do more than just record you,” Fast
Company , Mar /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https://www.fastcompany.com//three.lf/zero.lf/six.lf/one.lf/nine.lf/three.lf/five.lf/
police-body-cameras-livestreaming-face-recognition-and-ai
[/one.lf/three.lf/zero.lf] J. Peterson, J. Krug, M. Zoltu, A. K. Williams, and S. Alexander, “Augur:
A decentralized oracle and prediction market platform (v/two.lf./zero.lf),” arXiv preprint
arXiv:/one.lf/five.lf/zero.lf/one.lf./zero.lf/one.lf/zero.lf/four.lf/two.lf, Forecast Foundation, /two.lf/zero.lf/one.lf/nine.lf. [Online]. Available: https://arxiv.org/
abs//one.lf/five.lf/zero.lf/one.lf./zero.lf/one.lf/zero.lf/four.lf/two.lf
[/one.lf/three.lf/one.lf] N. Popper, Digital Gold: Bitcoin and the Inside Story of the Misﬁts and Millionaires Trying
to Reinvent Money . New York: HarperCollins, /two.lf/zero.lf/one.lf/six.lf.
[/one.lf/three.lf/two.lf] ——, “A hacking of more than /five.lf/zero.lf million dashes hopes in the world
of virtual currency,” The New York Times , Jun /two.lf/zero.lf/one.lf/six.lf. [Online]. Avail-
able: https://www.nytimes.com//two.lf/zero.lf/one.lf/six.lf//zero.lf/six.lf//one.lf/eight.lf/business/dealbook/hacker-may-have-
removed-more-than-/five.lf/zero.lf-million-from-experimental-cybercurrency-project.html
[/one.lf/three.lf/three.lf] R. Powell, “War as a commitment problem,” International Organization , vol. /six.lf/zero.lf, no. /one.lf,
pp. /one.lf/six.lf/nine.lf–/two.lf/zero.lf/three.lf, /two.lf/zero.lf/zero.lf/six.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/one.lf/seven.lf/S/zero.lf/zero.lf/two.lf/zero.lf/eight.lf/one.lf/eight.lf/three.lf/zero.lf/six.lf/zero.lf/six.lf/zero.lf/zero.lf/six.lf/one.lf.
[/one.lf/three.lf/four.lf] F. Reid and M. Harrigan, “An analysis of anonymity in the bitcoin system,” in Security
and Privacy in Social networks , Y. Altshuler, Y. Elovici, A. B. Cremers, N. Aharony, and
/eight.lf/four.lf
A. Pentland, Eds. New York: Springer, /two.lf/zero.lf/one.lf/three.lf, pp. /one.lf/nine.lf/seven.lf–/two.lf/two.lf/three.lf, doi:/one.lf/zero.lf./one.lf/zero.lf/zero.lf/seven.lf//nine.lf/seven.lf/eight.lf-/one.lf-/four.lf/six.lf/one.lf/four.lf-
/four.lf/one.lf/three.lf/nine.lf-/seven.lf\_/one.lf/zero.lf.
[/one.lf/three.lf/five.lf] C. Reitwiessner, “An update on integrating Zcash on Ethereum (ZoE),” Ethereum
Blog, Jan /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https://blog.ethereum.org//two.lf/zero.lf/one.lf/seven.lf//zero.lf/one.lf//one.lf/nine.lf/update-
integrating-zcash-ethereum/
[/one.lf/three.lf/six.lf] R. L. Rivest, A. Shamir, and L. Adleman, “A method for obtaining digital signatures
and public-key cryptosystems,” Communications of the ACM , vol. /two.lf/one.lf, no. /two.lf, pp. /one.lf/two.lf/zero.lf–
/one.lf/two.lf/six.lf, /one.lf/nine.lf/seven.lf/eight.lf, doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//three.lf/five.lf/nine.lf/three.lf/four.lf/zero.lf./three.lf/five.lf/nine.lf/three.lf/four.lf/two.lf.
[/one.lf/three.lf/seven.lf] S. Rosenberg, “Can an arcane crypto ledger replace Uber, Spotify and AirBnB?”
Wired , Jan /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: https://www.wired.com//two.lf/zero.lf/one.lf/six.lf//zero.lf/one.lf/can-an-
arcane-crypto-ledger-replace-uber-spotify-and-airbnb/
[/one.lf/three.lf/eight.lf] J. Rowlatt, “How Bitcoin’s vast energy use could burst its bubble,” BBC News , /two.lf/zero.lf/two.lf/one.lf.
[Online]. Available: https://www.bbc.co.uk/news/science-environment-/five.lf/six.lf/two.lf/one.lf/five.lf/seven.lf/eight.lf/seven.lf
[/one.lf/three.lf/nine.lf] A. Sahai and B. Waters, “How to use indistinguishability obfuscation: deniable en-
cryption, and more,” in Proceedings of the Forty-Sixth Annual ACM Symposium on The-
ory of Computing . ACM, /two.lf/zero.lf/one.lf/four.lf, pp. /four.lf/seven.lf/five.lf–/four.lf/eight.lf/four.lf, doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//two.lf/five.lf/nine.lf/one.lf/seven.lf/nine.lf/six.lf./two.lf/five.lf/nine.lf/one.lf/eight.lf/two.lf/five.lf.
[/one.lf/four.lf/zero.lf] N. Saper, “International cryptography regulation and the global information
economy,” Northwestern Journal of Technology and Intellectual Property , vol. /one.lf/one.lf,
no. /seven.lf, pp. /six.lf/seven.lf/three.lf–/six.lf/eight.lf/eight.lf, /two.lf/zero.lf/one.lf/three.lf. [Online]. Available: https://scholarlycommons.law.
northwestern.edu/njtip/vol/one.lf/one.lf/iss/seven.lf//five.lf
[/one.lf/four.lf/one.lf] E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers, E. Tromer, and M. Virza, “Ze-
rocash: Decentralized anonymous payments from bitcoin,” in /two.lf/zero.lf/one.lf/four.lf IEEE Symposium
on Security and Privacy . IEEE, /two.lf/zero.lf/one.lf/four.lf, pp. /four.lf/five.lf/nine.lf–/four.lf/seven.lf/four.lf, doi:/one.lf/zero.lf./one.lf/one.lf/zero.lf/nine.lf/SP./two.lf/zero.lf/one.lf/four.lf./three.lf/six.lf.
[/one.lf/four.lf/two.lf] T. C. Schelling, The Strategy of Conﬂict . Cambridge, MA: Harvard University Press,
/one.lf/nine.lf/eight.lf/zero.lf.
[/one.lf/four.lf/three.lf] N. Schick, Deep Fakes and the Infocalypse: What You Urgently Need to Know . London:
Hachette UK, /two.lf/zero.lf/two.lf/zero.lf.
[/one.lf/four.lf/four.lf] A. Schotter, The Economic Theory of Social Institutions . Cambridge, UK: Cambridge
University Press, /one.lf/nine.lf/eight.lf/one.lf.
[/one.lf/four.lf/five.lf] A. Segal, “Design and implementation of privacy-preserving surveillance,” Ph.D.
dissertation, Yale University, /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: https://search.proquest.
com/openview//seven.lf/eight.lf/one.lfbcd/nine.lfc/eight.lf/four.lf/four.lf/three.lfaaa/two.lf/eight.lfa/six.lf/three.lfb/zero.lf/six.lf/one.lfe/eight.lf/one.lfa/seven.lf/four.lfe/four.lf/
[/one.lf/four.lf/six.lf] A. Segal, B. Ford, and J. Feigenbaum, “Catching bandits and only bandits: Privacy-
preserving intersection warrants for lawful surveillance,” in /four.lfth USENIX Workshop
on Free and Open Communications on the Internet (FOCI /one.lf/four.lf) , /two.lf/zero.lf/one.lf/four.lf. [Online]. Available:
https://www.usenix.org/conference/foci/one.lf/four.lf/workshop-program/presentation/segal
/eight.lf/five.lf
[/one.lf/four.lf/seven.lf] M. J. Sergot, F. Sadri, R. A. Kowalski, F. Kriwaczek, P. Hammond, and H. T. Cory,
“The British Nationality Act as a logic program,” Communications of the ACM , vol. /two.lf/nine.lf,
no. /five.lf, pp. /three.lf/seven.lf/zero.lf–/three.lf/eight.lf/six.lf, /one.lf/nine.lf/eight.lf/six.lf, doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//five.lf/six.lf/eight.lf/nine.lf./five.lf/nine.lf/two.lf/zero.lf.
[/one.lf/four.lf/eight.lf] A. Shamir, “How to share a secret,” Communications of the ACM , vol. /two.lf/two.lf, no. /one.lf/one.lf, pp.
/six.lf/one.lf/two.lf–/six.lf/one.lf/three.lf, /one.lf/nine.lf/seven.lf/nine.lf, doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//three.lf/five.lf/nine.lf/one.lf/six.lf/eight.lf./three.lf/five.lf/nine.lf/one.lf/seven.lf/six.lf.
[/one.lf/four.lf/nine.lf] E. Silfversten, M. Favaro, L. Slapakova, S. Ishikawa, J. Liu, and A. Salas, “Exploring
the use of Zcash cryptocurrency for illicit or criminal purposes,” RAND, /two.lf/zero.lf/two.lf/zero.lf.
[Online]. Available: https://www.rand.org/pubs/research\_reports/RR/four.lf/four.lf/one.lf/eight.lf.html
[/one.lf/five.lf/zero.lf] G. Singh, “FIFE: A framework for investigating functional encryption,” Master’s
thesis, Massachusetts Institute of Technology, /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: https:
//dspace.mit.edu/handle//one.lf/seven.lf/two.lf/one.lf./one.lf//one.lf/zero.lf/six.lf/three.lf/seven.lf/five.lf
[/one.lf/five.lf/one.lf] N. P. Smart, Cryptography Made Simple . Cham, Switzerland: Springer, /two.lf/zero.lf/one.lf/six.lf.
[/one.lf/five.lf/two.lf] D. J. Solove, Nothing to Hide: The False Tradeo/f\_f.liga between Privacy and Security . New
Haven: Yale University Press, /two.lf/zero.lf/one.lf/one.lf.
[/one.lf/five.lf/three.lf] Sta/f\_f.liga of Global Legal Research Directorate, “Regulation of cryptocurrency around
the world,” The Law Library of Congress, Tech. Rep., /two.lf/zero.lf/one.lf/eight.lf. [Online]. Available:
https://www.loc.gov/law/help/cryptocurrency/world-survey.php
[/one.lf/five.lf/four.lf] J. Stark, “Making sense of cryptoeconomics,” CoinDesk, Aug /two.lf/zero.lf/one.lf/seven.lf. [Online].
Available: https://www.coindesk.com/making-sense-cryptoeconomics/
[/one.lf/five.lf/five.lf] “Distribution of Bitcoin’s network hashrate in the last /two.lf/four.lf hours until February
/one.lf/seven.lf, /two.lf/zero.lf/two.lf/one.lf,” Statista, /two.lf/zero.lf/two.lf/one.lf. [Online]. Available: https://www.statista.com/statistics/
/seven.lf/three.lf/one.lf/four.lf/one.lf/six.lf/market-share-of-mining-pools/
[/one.lf/five.lf/six.lf] K. Stinchcombe, “Ten years in, nobody has come up with a use for blockchain,”
Hackernoon , /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https://medium.com/@kaistinchcombe/ten-
years-in-nobody-has-come-up-with-a-use-case-for-blockchain-ee/nine.lf/eight.lfc/one.lf/eight.lf/zero.lf/one.lf/zero.lf/zero.lf
[/one.lf/five.lf/seven.lf] M. Swan, Blockchain: Blueprint for a New Economy . Sebastopol, CA: O’Reilly, /two.lf/zero.lf/one.lf/five.lf.
[/one.lf/five.lf/eight.lf] J. Swearingen, “Something weird (or weirder than normal) is happening at
WikiLeaks,” New York , Nov /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: http://nymag.com/selectall/
/two.lf/zero.lf/one.lf/six.lf//one.lf/one.lf/wikileak-hashes-dont-match-so-whats-going-on.html
[/one.lf/five.lf/nine.lf] N. Szabo, “The idea of smart contracts,” /one.lf/nine.lf/nine.lf/seven.lf. [Online]. Available: https:
//nakamotoinstitute.org/the-idea-of-smart-contracts/
[/one.lf/six.lf/zero.lf] R. Talviste, “Applying secure multi-party computation in practice,” Ph.D.
dissertation, University of Tartu, /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: https://core.ac.uk/
download/pdf//one.lf/four.lf/four.lf/seven.lf/zero.lf/eight.lf/nine.lf/three.lf/one.lf.pdf
/eight.lf/six.lf
[/one.lf/six.lf/one.lf] J. Tang, A. Korolova, X. Bai, X. Wang, and X. Wang, “Privacy loss in
Apple’s implementation of di/f\_f.ligaerential privacy on MacOS /one.lf/zero.lf./one.lf/two.lf,” arXiv preprint
arXiv:/one.lf/seven.lf/zero.lf/nine.lf./zero.lf/two.lf/seven.lf/five.lf/three.lf, /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: https://arxiv.org/abs//one.lf/seven.lf/zero.lf/nine.lf./zero.lf/two.lf/seven.lf/five.lf/three.lf
[/one.lf/six.lf/two.lf] M. Taylor and S. Singleton, “The communal resource: Transaction costs and the
solution of collective action problems,” Politics & Society , vol. /two.lf/one.lf, no. /two.lf, pp. /one.lf/nine.lf/five.lf–/two.lf/one.lf/four.lf,
/one.lf/nine.lf/nine.lf/three.lf, doi:/one.lf/zero.lf./one.lf/one.lf/seven.lf/seven.lf//zero.lf/zero.lf/three.lf/two.lf/three.lf/two.lf/nine.lf/two.lf/nine.lf/three.lf/zero.lf/two.lf/one.lf/zero.lf/zero.lf/two.lf/zero.lf/zero.lf/four.lf.
[/one.lf/six.lf/three.lf] J. Tirole, “Incomplete contracts: Where do we stand?” Econometrica , vol. /six.lf/seven.lf, no. /four.lf,
pp. /seven.lf/four.lf/one.lf–/seven.lf/eight.lf/one.lf, /one.lf/nine.lf/nine.lf/nine.lf, doi:/one.lf/zero.lf./one.lf/one.lf/one.lf/one.lf//one.lf/four.lf/six.lf/eight.lf-/zero.lf/two.lf/six.lf/two.lf./zero.lf/zero.lf/zero.lf/five.lf/two.lf.
[/one.lf/six.lf/four.lf] P. Todd, “Cypherpunk desert bus: My role in the /two.lf/zero.lf/one.lf/six.lf Zcash trusted setup
ceremony,” Nov /two.lf/zero.lf/one.lf/six.lf. [Online]. Available: https://petertodd.org//two.lf/zero.lf/one.lf/six.lf/cypherpunk-
desert-bus-zcash-trusted-setup-ceremony
[/one.lf/six.lf/five.lf] A. Trask, “Building safe A.I.: A tutorial for encrypted deep learning,” March /two.lf/zero.lf/one.lf/seven.lf.
[Online]. Available: https://iamtrask.github.io//two.lf/zero.lf/one.lf/seven.lf//zero.lf/three.lf//one.lf/seven.lf/safe-ai/
[/one.lf/six.lf/six.lf] ——, “Safe crime detection: Homomorphic encryption and deep learning for
more e/f\_f.ligaective, less intrusive digital surveillance,” Jun /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available:
https://iamtrask.github.io//two.lf/zero.lf/one.lf/seven.lf//zero.lf/six.lf//zero.lf/five.lf/homomorphic-surveillance/
[/one.lf/six.lf/seven.lf] A. Trask, E. Bluemke, B. Gar/fi.ligankel, C. G. Cuervas-Mons, and A. Dafoe, “Beyond
privacy trade-o/f\_f.ligas with structured transparency,” arXiv preprint arXiv:/two.lf/zero.lf/one.lf/two.lf./zero.lf/eight.lf/three.lf/four.lf/seven.lf,
/two.lf/zero.lf/two.lf/zero.lf. [Online]. Available: https://arxiv.org/abs//two.lf/zero.lf/one.lf/two.lf./zero.lf/eight.lf/three.lf/four.lf/seven.lf
[/one.lf/six.lf/eight.lf] M. Tsukerman, “The block is hot: A survey of the state of Bitcoin regulation and
suggestions for the future,” Berkeley Technology Law Journal , vol. /three.lf/zero.lf, no. Annual
Review, pp. /one.lf/one.lf/two.lf/seven.lf–/one.lf/one.lf/seven.lf/zero.lf, /two.lf/zero.lf/one.lf/five.lf. [Online]. Available: https://btlj.org/data/articles/two.lf/zero.lf/one.lf/five.lf/
vol/three.lf/zero.lf//three.lf/zero.lf\_AR//one.lf/one.lf/two.lf/seven.lf-/one.lf/one.lf/seven.lf/zero.lf\_Tsukerman\_Final%/two.lf/zero.lf/one.lf/one.lf/one.lf/nine.lf/one.lf/five.lf.pdf
[/one.lf/six.lf/nine.lf] C. Turley, “Moloch evolved: V/two.lf primer,” Raid Guild , /two.lf/zero.lf/two.lf/zero.lf. [Online]. Available:
https://medium.com/raid-guild/moloch-evolved-v/two.lf-primer-/two.lf/five.lfc/nine.lfcdeab/four.lf/five.lf/five.lf
[/one.lf/seven.lf/zero.lf] M. Une, “The security evaluation of time stamping schemes: The present
situation and studies,” IMES Discussion Papers Series /two.lf/zero.lf/zero.lf/one.lf-E-/one.lf/eight.lf, Institute for
Monetary and Economic Studies, Bank of Japan, /two.lf/zero.lf/zero.lf/one.lf. [Online]. Available:
https://www.imes.boj.or.jp/research/papers/english//zero.lf/one.lf-E-/one.lf/eight.lf.pdf
[/one.lf/seven.lf/one.lf] V. Vaikuntanathan, “Computing blindfolded: New developments in fully homomor-
phic encryption,” in /two.lf/zero.lf/one.lf/one.lf IEEE /five.lf/two.lfnd Annual Symposium on Foundations of Computer
Science (FOCS) . IEEE, /two.lf/zero.lf/one.lf/one.lf, pp. /five.lf–/one.lf/six.lf, doi:/one.lf/zero.lf./one.lf/one.lf/zero.lf/nine.lf/FOCS./two.lf/zero.lf/one.lf/one.lf./nine.lf/eight.lf.
[/one.lf/seven.lf/two.lf] J. van den Hoo/f\_f.liga, D. Lazar, M. Zaharia, and N. Zeldovich, “Vuvuzela: Scalable pri-
vate messaging resistant to tra/f\_f\_i.ligac analysis,” in Proceedings of the /two.lf/five.lfth Symposium on
Operating Systems Principles . ACM, /two.lf/zero.lf/one.lf/five.lf, pp. /one.lf/three.lf/seven.lf–/one.lf/five.lf/two.lf, doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//two.lf/eight.lf/one.lf/five.lf/four.lf/zero.lf/zero.lf./two.lf/eight.lf/one.lf/five.lf/four.lf/one.lf/seven.lf.
[/one.lf/seven.lf/three.lf] P. Vigna and M. J. Casey, “Bitcoin for the unbanked,” Foreign A/f\_f.ligaairs , /two.lf/zero.lf/one.lf/five.lf. [Online].
/eight.lf/seven.lf
Available: https://www.foreigna/f\_f.ligaairs.com/articles//two.lf/zero.lf/one.lf/five.lf-/zero.lf/two.lf-/two.lf/six.lf/bitcoin-unbanked
[/one.lf/seven.lf/four.lf] J. Vogler, The Global Commons: Environmental and Technological Governance . West
Sussex, England: Wiley, /two.lf/zero.lf/zero.lf/zero.lf.
[/one.lf/seven.lf/five.lf] G. Volpicelli, “How the blockchain is helping stop the spread of con/fl.ligaict
diamonds,” Wired UK , Feb /two.lf/zero.lf/one.lf/seven.lf. [Online]. Available: http://www.wired.co.uk/
article/blockchain-con/fl.ligaict-diamonds-everledger
[/one.lf/seven.lf/six.lf] D. Vorick and L. Champine, “Sia: Simple decentralized storage,” /two.lf/zero.lf/one.lf/four.lf. [Online].
Available: https://sia.tech/sia.pdf
[/one.lf/seven.lf/seven.lf] S. Wagh, S. Tople, F. Benhamouda, E. Kushilevitz, P. Mittal, and T. Rabin, “FAL-
CON: Honest-majority maliciously secure framework for private deep learning,”
Proceedings on Privacy Enhancing Technologies , vol. /two.lf/zero.lf/two.lf/one.lf, no. /one.lf, pp. /one.lf/eight.lf/eight.lf–/two.lf/zero.lf/eight.lf, /two.lf/zero.lf/two.lf/one.lf,
doi:/one.lf/zero.lf./two.lf/four.lf/seven.lf/eight.lf/popets-/two.lf/zero.lf/two.lf/one.lf-/zero.lf/zero.lf/one.lf/one.lf.
[/one.lf/seven.lf/eight.lf] M. Wal/fi.ligash and A. J. Blumberg, “Verifying computations without reexecuting them,”
Communications of the ACM , vol. /five.lf/eight.lf, no. /two.lf, pp. /seven.lf/four.lf–/eight.lf/four.lf, /two.lf/zero.lf/one.lf/five.lf, doi:/one.lf/zero.lf./one.lf/one.lf/four.lf/five.lf//two.lf/six.lf/four.lf/one.lf/five.lf/six.lf/two.lf.
[/one.lf/seven.lf/nine.lf] M. Walport, “Distributed ledger technology: beyond block chain,”
United Kingdom Government O/f\_f\_i.ligace for Science, /two.lf/zero.lf/one.lf/five.lf. [Online]. Avail-
able: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/
attachment\_data//fi.ligale//four.lf/nine.lf/two.lf/nine.lf/seven.lf/two.lf/gs-/one.lf/six.lf-/one.lf-distributed-ledger-technology.pdf
[/one.lf/eight.lf/zero.lf] O. E. Williamson, The Economic Institutions of Capitalism: Firms, Markets, Relational
Contracting . New York: Macmillan, /one.lf/nine.lf/eight.lf/five.lf.
[/one.lf/eight.lf/one.lf] B. Wittes and G. Blum, The Future of Violence: Robots and Germs, Hackers and Drones–
Confronting A New Age of Threat . New York: Basic Books, /two.lf/zero.lf/one.lf/five.lf.
[/one.lf/eight.lf/two.lf] A. Wright and P. De Filippi, “Decentralized blockchain technology and the rise of
lex cryptographia,” /two.lf/zero.lf/one.lf/five.lf, doi:/one.lf/zero.lf./two.lf/one.lf/three.lf/nine.lf/ssrn./two.lf/five.lf/eight.lf/zero.lf/six.lf/six.lf/four.lf.
[/one.lf/eight.lf/three.lf] L. Xie, “A beginner’s guide to DAOs,” Mirror, /two.lf/zero.lf/two.lf/one.lf. [Online]. Available:
https://linda.mirror.xyz/Vh/eight.lfK/four.lfleCGEO/zero.lf/six.lf\_qSGx-vS/five.lflvgUqhqkCz/nine.lfut/eight.lf/one.lfWwCP/two.lfo
[/one.lf/eight.lf/four.lf] A. Yakovenko, “Solana: A new architecture for a high performance blockchain
v/zero.lf./eight.lf./one.lf/four.lf,” Solana Labs, /two.lf/zero.lf/one.lf/eight.lf.
[/one.lf/eight.lf/five.lf] A. C. Yao, “Protocols for secure computations,” in /two.lf/three.lfrd Annual Symposium on Foun-
dations of Computer Science . IEEE, /one.lf/nine.lf/eight.lf/two.lf, pp. /one.lf/six.lf/zero.lf–/one.lf/six.lf/four.lf, doi:/one.lf/zero.lf./one.lf/one.lf/zero.lf/nine.lf/SFCS./one.lf/nine.lf/eight.lf/two.lf./three.lf/eight.lf.
[/one.lf/eight.lf/six.lf] “What are zk-SNARKs?” Zcash. [Online]. Available: https://z.cash/technology/
zksnarks.html
[/one.lf/eight.lf/seven.lf] G. Zyskind, O. Nathan, and A. Pentland, “Enigma: Decentralized computation
platform with guaranteed privacy,” arXiv preprint arXiv:/one.lf/five.lf/zero.lf/six.lf./zero.lf/three.lf/four.lf/seven.lf/one.lf, /two.lf/zero.lf/one.lf/five.lf. [Online].
/eight.lf/eight.lf
Available: https://arxiv.org/abs//one.lf/five.lf/zero.lf/six.lf./zero.lf/three.lf/four.lf/seven.lf/one.lf
/eight.lf/nine.lf
A Relevance of progress in arti/fi.ligacial intelligence
The signi/fi.ligacance of technological developments in one /fi.ligaeld often depends on what devel-
opments occur in other /fi.ligaelds. For example, the signi/fi.ligacance of last century’s developments
in cryptography would not have been nearly so great if it hadn’t been for the creation of
the internet and other novel communications technologies.
To take into account these interaction e/f\_f.ligaects, this section will brie/fl.ligay consider some of
the ways in which progress in arti/fi.ligacial intelligence and progress in cryptography could be
relevant to one another.
I list seven potential interaction points.
A./one.lf AI systems may enable more e/f\_f.ligaective surveillance
Progress in AI could enable more e/f\_f.ligaective surveillance by decreasing the cost of extracting
information from collected data [/four.lf/five.lf, /four.lf]. It is plausible, for example, that AI systems applied
to videos, messages, and social networks could become fairly e/f\_f.ligaective at automatically
identifying criminals, dissidents, or other groups that state actors would have an interest
in discovering, without the need for humans to sift through the relevant data by hand.
However, as discussed in section /three.lf./one.lf./one.lf, this trend might be undermined by developments
in cryptography—speci/fi.ligacally, by a move toward greater and more e/f\_f.ligaective use of end-to-
end encryption, cryptocurrencies capable of obscuring transaction details, and methods of
computing on con/fi.ligadential data which reduce the need for companies to collect personal
information.
A./two.lf AI systems may help to make privacy-preserving surveillance feasi-
ble
If AI systems /fi.ligand greater applications in surveillance, then this could also open the door
for surveillance that o/f\_f.ligaers a greater degree of privacy.
As discussed in section /three.lf./one.lf./two.lf, one way to achieve this result is to apply techniques for com-
puting on con/fi.ligadential data. These techniques could make it possible to extract security-
relevant information from surveillance data without having access to it in unencrypted
form.
In addition, AI systems could also enable privacy-preserving surveillance more directly.
The point, here, is that encryption is only one way to prevent users from gaining access to
extraneous information in surveillance data. It is also possible to obfuscate data in a more
direct manner, for example by removing labels or, in di/f\_f.ligaerential privacy techniques, by
adding random alterations [/two.lf]. Similarly, AI systems may be able to perform more precise
censorship of collected data. An early example of this idea is the proposed use of face-
blurring algorithms for police body-camera footage [/one.lf/two.lf/nine.lf].
/nine.lf/zero.lf
A./three.lf AI systems may increase the need for anti-forgery schemes
Progress in AI continues to make fake photographs and videos more convincing and cheap
to produce [/four.lf/nine.lf]. If this trend continues, it could become increasingly di/f\_f\_i.ligacult to distin-
guish true claims from false ones, with important negative consequences for politics, law
enforcement, and news reporting [/four.lf]. Schemes of the sort described in section /three.lf./one.lf./four.lf, which
use trusted timestamping to provide evidence for the veracity of images, could be impor-
tant tools for avoiding these consequences.
A./four.lf Methods of computing on con/fi.ligadential data could reduce barriers
to developing certain AI systems
Developing AI systems using machine learning methods typically requires access to large
volumes of relevant data. Con/fi.ligadentiality concerns are therefore one natural barrier to
AI development in certain domains. For example, for good reason, it is typically rather
di/f\_f\_i.ligacult to gain access to large volumes of medical data, even if this data could be used in
a socially bene/fi.ligacial fashion.
Methods of computing on con/fi.ligadential data (see sections /two.lf./one.lf/one.lf–/two.lf./one.lf/three.lf), particularly secure
multiparty computation techniques, could reduce con/fi.ligadentiality concerns as a barrier to
AI development. While other techniques in privacy-preserving machine learning, such as
di/f\_f.ligaerential privacy, do exist, they are less generally applicable and su/f\_f.ligaer from signi/fi.ligacant
trade-o/f\_f.ligas between how e/f\_f.ligaective they are at preserving privacy and how much they still
allow machines to learn [/two.lf].
One illustrative project here is OpenMined, which aims to make it much easier for users
to contribute their data to machine learning projects that are conducted in a privacy-
preserving fashion [/one.lf/two.lf/six.lf].
A./five.lf The problems of safe AI design and safe smart contract design may
be connected
One broad problem in the emerging /fi.ligaeld of “AI safety” is the problem of designing AI
systems that will not exhibit unintended harmful behaviors [/five.lf, /four.lf]. For instance, there is
not yet any general method for ensuring that an AI system trained or programmed to
behave well in a limited set of environments will not cause accidents if it is deployed in a
wider range of real-world environments. We can already point to examples of AI accidents
such as the /two.lf/zero.lf/one.lf/zero.lf “/fl.ligaash crash,” in which the behavior of automated trading systems caused a
trillion-dollar stock market crash, and fatal collisions that have occurred with self-driving
cars. In the future, as AI systems are used to automate increasingly complex and crucial
tasks, techniques for avoiding accidents could become much more important [/two.lf/eight.lf].
Similarly, as discussed in section /four.lf./two.lf./four.lf, one important factor restricting the applications of
smart contracts is the need to ensure that they will behave as intended. The problem here
is made especially severe by the fact that smart contracts cannot be modi/fi.ligaed once created.
The infamous collapse of the /dollar.lf/one.lf/five.lf/zero.lf million DAO venture capital fund, described in section
/three.lf./two.lf./four.lf, is a good illustration of the need to get smart contracts right [/one.lf/three.lf/two.lf].
/nine.lf/one.lf
With such incidents in mind, Vitalik Buterin has written that the problem of designing
reliable AI systems and the problem of designing reliable smart contracts overlap, and that
researchers working on each of these problems could bene/fi.ligat from talking to those working
on the other [/four.lf/zero.lf].
As a point of disanalogy, however, it is important to note that current “scalability” con-
straints (see section /four.lf./two.lf./one.lf) severely limit the amount of computing power that smart con-
tracts can draw from, to the extent that it is non-trivial to implement something even so
simple as a smart contract that judges who has won a game of chess. This means that smart
contracts are quite distinct from the advanced AI systems that AI safety researchers pri-
marily have in mind. Speci/fi.ligacally, this also means that, barring extremely large increases
in available computing power, no non-trivial AI system could actually be run as a smart
contract./five.lf/four.lf
A./six.lf New coordination and veri/fi.ligacation mechanisms may be useful for
governing AI systems
Generally, if progress in AI creates new security challenges—for example, by enabling au-
tonomous weapons systems, more damaging categories of cyberweapons, or other systems
associated with substantial accident risks—then there could be a need for international
agreements and other forms of global governance to guide its application and develop-
ment [/nine.lf/zero.lf, /two.lf/nine.lf, /three.lf/two.lf]. If smart contracts ever become su/f\_f\_i.ligaciently reliable, then it is possi-
ble—although, for reasons discussed in section /four.lf./two.lf./three.lf, probably not very likely—that they
could have applications in enforcing such agreements. Similarly, it is possible that zero-
knowledge proofs or methods for computing on con/fi.ligadential data could make it easier
to verify compliance without requiring the relevant parties to share too much sensitive
information (see section /three.lf./one.lf./three.lf).
A./seven.lf Fully homomorphic encryption may have applications in AI safety
and security
As described in an essay by Andrew Trask, fully homomorphic encryption could make it
possible to train AI systems using encrypted data or encrypted virtual environments [/one.lf/six.lf/five.lf].
The result of such training would be systems that cannot interact with the world, as they
are only capable of processing encrypted inputs and providing encrypted outputs. Plausi-
bly, such systems would o/f\_f.ligaer more security against attempts at theft and premature real-
world use (e.g., before safety properties are guaranteed). The idea is that the system would
only be able to interact with speci/fi.ligac encrypted digital environments, which might still be
useful for testing or further training, until the system is itself decrypted. Note, again, that
the future practicality of such a scheme would depend on the amount of computing power
required for fully homomorphic encryption, as well as the amount of computing power
available (see section /four.lf./one.lf./one.lf).
/five.lf/four.lfAt the same time, if smart contracts that “outsource” computations to other users become more common
(see section /four.lf./two.lf./one.lf), then the problems of AI safety and smart contract safety could become more concretely inter-
twined. If the relevant techniques become su/f\_f\_i.ligaciently e/f\_f\_i.ligacient and reliable, then there could arise smart contracts
that pay others to run more powerful AI systems, so that the systems are likely to continue running so long as
the smart contract does.
/nine.lf/two.lf
May 2021
Centre for the Governance of AI,
Future of Humanity Institute,
University of Oxford
www.governance.ai