April 19, 2019

The Trust Architecture of Blockchain: Kevin Werbach at CITP

In 2009, bitcoin inventor Satoshi Nakomoto argued that it was “a system for electronic transactions without relying on trust.”

That’s not true, according to today’s CITP’s speaker Kevin Werbach (@kwerb), a professor of Legal Studies and Business Ethics at the Wharton School at UPenn. Kevin is author of a new book with MIT Press, The Blockchain and the New Architecture of Trust.

A world-renowned expert on emerging technology, Kevin examines business and policy implications of developments such as broadband, big data, gamification, and blockchain. Kevin served on the Obama Administration’s Presidential Transition Team, founded the Supernova Group (a technology conference and consulting firm) and helped develop the U.S. approach to internet policy during the Clinton Administration.

Blockchain does actually rely on trust, says Kevin. He tells us the story of the cryptocurrency exchange QuadrigaCX, who claimed that millions of dollars in cryptocurrency were lost when their CEO passed away. While whole story was more complex, Kevin says, it reveals how much bitcoin transactions rely on many kinds of trust.

Rather than removing the need for trust, blockchain offers a new architecture of trust compared to previous models. Peer to peer trust is based on personal relationships.  Leviathan trust, described by Hobbes, is a social contract with the state, which then has the power to enforce private agreements between people. The power of the state makes us more trusting in the private relationships– if you trust the state and if the legal system works. Intermediary trust involves a central entity that manages transactions between people

Blockchain is a new kind of trust, says Kevin. With blockchain trust, you can trust the ledger without (so it seems) trusting any actor to validate it. For this to work, transactions need to be very hard to change without central control – if anyone had the power to make changes, you would have to trust them.

Why would anyone value the blockchain? Blockchain minimizes the need for certain kinds of trust: removing single points of failure, reducing risks of monopoly, and reduces friction from the intermediation. Blockchain also expands trust by minimizing reconciliation, carries out automated execution, and increases the auditability of records.

What could possibly go wrong? Even if the blockchain ledger is auditable and trustworthy, the transaction record isn’t the whole system. Kevin points out that 80% of all bitcoin users rely on centralized key storage. He also reported figures that 20-80% of all Initial Coin Offerings were fraudulent.

Kevin tells us about “Vlad’s conundrum”- there’s a direct conflict between the design of the blockchain system and any regulatory model. The blockchain doesn’t know the difference between transactions, and there’s no entity that can say “no, that’s not okay.” Kevin tells us about the use of the blockchain for money laundering and financing terrorism. He also tells us about the challenge of moderating child pornography data that has been distributed across the blockchain- exposing every bitcoin node to legal risks.

None of these risks are as simple as they seem. Legal enforcement is carried out by humans who often consider intent. Simply possessing digital bits that represent child pornography data will not doom bitcoin. Furthermore, systems are less decentralized or anonymous than they appear. Regulations about parts of the system at the edges and endpoints of the blockchain can promote trust and innovation. Regulators have often been able to pull systems apart, find the involved parties, and hold actors accountable.

Kevin argues that designers of blockchain systems have to manage three trade-offs. Trust, freedom of action, and convenience. Any designer of a system will have to make hard choices about the tradeoffs among each of these factors.

aCiting Vili Lehdonvirta’s blockchain paradox, Kevin tells us several stories about ways that centralized governance processes managed serious problems and fraud in blockchain systems that would have been problems if governance had purely been decentralized.  Kevin also describes technical mechanisms for governance: voting systems, special kinds of contracts, arbitration schemes, and dispute resolution processes

Overall, Kevin tells us that blockchain governance comes back to trust– which shapes how we act with confidence in circumstances of uncertainty and vulnerability.

What’s new with BlockSci, Princeton’s blockchain analysis tool

Six months ago we released the initial version of BlockSci, a fast and expressive tool to analyze public blockchains. In the accompanying paper we explained how we used it to answer scientific questions about security, privacy, miner behavior, and economics using blockchain data. BlockSci has a number of other applications including forensics and as an educational tool.

Since then we’ve heard from a number of researchers and developers who’ve found it useful, and there’s already a published paper on ransomware that has made use of it. We’re grateful for the pull requests and bug reports on GitHub from the community. We’ve also used it to deep-dive into some of the strange corners of blockchain data. We’ve made enhancements including a 5x speed improvement over the initial version (which was already several hundred times faster than previous tools).

Today we’re happy to announce BlockSci 0.4.5, which has a large number of feature enhancements and bug fixes. As just one example, Bitcoin’s SegWit update introduces the concept of addresses that have different representations but are equivalent; tools such as blockchain.info are confused by this and return incorrect (or at least unexpected) values for the balance held by such addresses. BlockSci handles these nuances correctly. We think BlockSci is now ready for serious use, although it is still beta software. Here are a number of ideas on how you can use it in your projects or contribute to its development.

We plan to release talks and tutorials on BlockSci, and improve its documentation. I’ll give a brief talk about it at the MIT Bitcoin Expo this Saturday; then Harry Kalodner and Malte Möser will join me for a BlockSci tutorial/workshop at MIT on Monday, March 19, organized by the Digital Currency Initiative and Fidelity Labs. Videos of both events will be available.

We now have two priorities for the development of BlockSci. The first is to make it possible to implement almost all analyses in Python with the speed of C++. To enable this we are building a function composition interface to automatically translate Python to C++. The second is to better support graph queries and improved clustering of the transaction graph. We’ve teamed up with our colleagues in the theoretical computer science group to adapt sophisticated graph clustering algorithms to blockchain data. If this effort succeeds, it will be a foundational part of how we understand blockchains, just as PageRank is a fundamental part of how we understand the structure of the web. Stay tuned!

Blockchain: What is it good for?

Blockchain and cryptocurrencies are surrounded by world-historic levels of hype and snake oil. For people like me who take the old-fashioned view that technical claims should be backed by sound arguments and evidence, it’s easy to fall into the trap of concluding that there is no there there–and that blockchain and cryptocurrencies are fundamentally useless. This post is my attempt to argue that if we strip away the fluff, some valuable computer science ideas remain.

Let’s start by setting aside the currency part, for now, and focusing on blockchains. The core idea goes back to at least the 1990s: replicate a system’s state across a set of machines; use some kind of distributed consensus algorithm to agree on an append-only log of events that change the state; and use cryptographic hash-chaining to make the log tamper-evident. Much of the legitimate excitement about “blockchain” is driven by the use of this approach to enhance transparency and accountability, by making certain types of actions in a system visible. If an action is recorded in your blockchain, everyone can see it. If it is not in your blockchain, it is ignored as invalid.

An example of this basic approach is certificate transparency, in which certificate authorities (“CAs,” which vouch for digital certificates connecting a cryptographic key to the owner of a DNS name) must publish the certificates they issue on a public list, and systems refuse to accept certificates that are not on the list. This ensures that if a CA issues a certificate without permission from a name’s legitimate owner, the bogus certificate cannot be used without publishing it and thereby enabling the legitimate owner to raise an alarm, potentially leading to public consequences for the misbehaving CA.

In today’s world, with so much talk about the policy advantages of technological transparency, the use of blockchains for transparency can an important tool.

What about cryptocurrencies? There is a lot of debate about whether systems like Bitcoin are genuinely useful as a money transfer technology. Bitcoin has many limitations: transactions take a long time to confirm, and the mining-based consensus mechanism burns a lot of energy. Whether and how these limitations can be overcome is a subject of current research.

Cryptocurrencies are most useful when coupled with “smart contracts,” which allow parties to define the behavior of a virtual actor in code, and have the cryptocurrency’s consensus system enforce that the virtual actor behaves according to its code. The name “smart contract” is misleading, because these mechanisms differ significantly from legal contracts.  (A legal contract is an explicit agreement among an enumerated set of parties that constrains the behavior of those parties and is enforced by ex post remedies. A “smart contract” doesn’t require explicit agreement from parties, doesn’t enumerate participating parties, doesn’t constrain behavior of existing parties but instead creates a new virtual party whose behavior is constrained, and is enforced by ex ante prevention of deviations.) It is precisely these differences that make “smart contracts” useful.

From a computer science standpoint, what is exciting about “smart contracts” is that they let us make conditional payments an integral part of the toolbox for designing distributed protocols. A party can be required to escrow a deposit as a condition of participating in some process, and the return of that deposit, in part or in whole, can be conditioned on the party performing arbitrary required steps, as long as compliance can be checked by a computation.

Another way of viewing the value of “smart contracts” is by observing that we often define correctness for a new distributed protocol by postulating a hypothetical trusted third party who “referees” the protocol, and then proving some kind of equivalence between the new referee-free protocol we have designed and the notional refereed protocol. It sure would be nice if we could just turn the notional referee into a smart contract and let the consensus system enforce correctness.

But all of this requires a “smart contract” system that is efficient and scalable–otherwise the cost of using “smart contracts” will be excessive. Existing systems like Ethereum scale poorly. This too is a problem that will need to be overcome by new research. (Spoiler alert: We’ll be writing here about a research solution in the coming months.)

These are not the only things that blockchain and cryptocurrencies are good for. But I hope they are convincing examples. It’s sad that the hype and snake oil has gotten so extreme that it can be hard to see the benefits. The benefits do exist.