known cryptographic protocols could
be done in a number of ways. Doing it
on top of a system such as blockchain
is needed if the requirement that the
system be trustless (except for trusting
the software) is added. Such a trustless
system comes with a cost.
Whether the cost is worth it is a decision that requires an understanding
of the various parts of the system and
how they interact. A public, unforgeable, unchangeable ledger is possible
without cryptocurrency or a consensus
algorithm based on a difficult-to-com-pute one-way function that is easily verified. Cryptocurrencies can be created
without the use of either a public ledger or a trustless consensus algorithm.
And consensus algorithms can be created that do not require a financial incentive system or a public ledger.
Bitcoin’s Academic Pedigree
Arvind Narayanan and Jeremy Clark
Research for Practice: Cryptocurrencies,
Blockchains, and Smart Contracts;
Hardware for Deep Learning
Ben Laurie, Google
1. Bitcoinblockhalf.com. Bitcoin block reward halving
2. Blockchain.com. Confirmed transactions per day,
3. Fischer, M., Lynch, N.A., Paterson, M. Impossibility of
distributed consensus with one faulty process. JACM
32, 2 (1985), 374–382.
4. Lamport, L. The part-time parliament. ACM Trans.
Computer Systems 16, 2 (1998), 133–169.
5. Morris, D.Z. Bitcoin is in wild upheaval after the
cancellation of the Segwit2x fork. Fortune (Nov.
12, 2017); http://fortune.com/2017/11/12/bitcoin-
6. Nakamoto, S. Bitcoin, a peer-to-peer electronic cash
system, 2008; https://bitcoin.org/bitcoin.pdf.
7. Thompson, K. Reflections on trusting trust. Commun.
ACM 27, 8 (Aug. 1984), 761–763; https://dl.acm.org/
8. Trubetskoy, G. Electricity cost of 1 bitcoin (Sept. 2017);
9. Yaga, D., Mell, P., Roby, N., Scarfone, K. Blockchain
technology overview. NISTIR 8202 (Oct. 2018).
National Institute of Standards and Technology;
Jim Waldo is a professor of the practice of computer
science at Harvard University, where he is also the chief
technology officer for the School of Engineering, a position
he assumed after leaving Sun Microsystems Laboratories.
Copyright held by author/owner.
Publication rights licensed to ACM.
hardware used for the hashing to something far more efficient (such as specialized ASICs). Making the hashing process more efficient, however, is at odds
with blockchain’s fundamental mechanism of trusting no one; the point is
that the verification of a block must be
difficult and random so that any miner
is equally likely to find the hash.
The energy consumption might
be less worrisome if the calculations
eating all of this power were generally useful. SETI@home, for example,
uses a considerable amount of energy
by offloading analysis of background
radio-wave transmissions to Internet-connected computers. This initiative,
based at UC Berkeley’s SETI (Search for
Extraterrestrial Intelligence) Research
Center, is trying to find signs of other
intelligent life in the universe, which is
seen by the participants as worth doing
(and paying for the extra electricity).
Perhaps the calculation used to verify the blockchain could be changed to
something that offered more than just
verification of the blockchain. Such
a calculation would need to have the
properties of being equally possible
for all miners to find (given equality of
computing resource), difficult to find,
and easy to verify. It is not clear what
this calculation might be.
Trust. Perhaps the most problematic aspect of blockchain is its core
notion of being trustless. Much of the
complexity of the technology is caused
by this requirement. It is unclear, however, that this is even necessary for the
kinds of uses people talk about as core
to blockchain, or that the system is actually free of trust.
It is because of the lack of trust
that the system requires verification
of the block to be computationally
difficult, one-way, and easy to verify.
If this requirement of trustlessness
were dropped, then production of a
public ledger that was unchangeable
and easily verified could be done easily. Suppose such a ledger is to be used
for inter-bank transfer (which has been
suggested as a use for blockchain). Instead of a trustless system, however,
the users decide to trust a consortium
of major banks, the Federal Reserve
Board, and some selection of consumer watchdog agencies or organizations.
This consortium could choose a mem-
ber (perhaps on a rotating basis) who
is responsible for keeping the ledger
(a leader). Transactions are written to
the ledger, and when the ledger block
reaches an appropriate size, the lead-
er hashes the ledger, uses the hash to
start a new block, and continues (just
as in the current blockchain).
The difference is that there is no
need for the leader to randomly try values added to the block until the right
number of leading zeros is produced
in the hash. Without that requirement,
the hash can be done very quickly with
little energy expense. The block still
can’t be changed (since the hash is still
a one-way function), and any member
of the consortium (or anyone else who
has access to the ledger) can quickly
check the hash. A public, verifiable,
and unchangeable ledger can be produced in this way but at much lower
cost in both time and energy.
This does require trust in the various
members of the consortium, but verifying that the consortium is not cheating on the hashing of a block would be
easy. This is not a fully centralized trust
in a single entity but, rather, trusting a
group. The larger and more varied the
group, the less likely the group would
collude. Note also that such a system
does not need an incentive mechanism
such as a digital currency to operate.
Who Do You Trust?
Maybe you really do not want to trust
anyone. Calibrating paranoia is difficult, and perhaps you really do want to
have an economic system in which no
specifiable set of entities has the ability
to collude and control the system. That
is the real reason for blockchain.
As Ken Thompson pointed out in
1984, trust has to happen somewhere.
Even if you do not trust any group to
calculate the blocks, you need to trust
the developers of the software being
used to manage the blocks, the ledgers,
and the rest. Everything from bugs to
design changes5 in the software have
led to forks in the bitcoin ecosystem
that have caused considerable churn
in those systems. If your trust is in the
security and solidity of the code, that is
a choice you make. But it is not a trustless system.
A public, nonrefutable, unalterable ledger for transactions could be
a useful tool for a number of applications. Building such a system on top of