A few weeks ago, I attended a workshop organized by the Initiative for Cryptocurrencies and Contracts (IC3).

IC3 is an initiative of faculty members at Cornell University, Cornell Tech, and UC Berkeley. Its mission is to advance the science and applications of blockchains. It is based at the Jacobs Technion-Cornell Institute at Cornell Tech in New York City.

The goal of the workshop held in New York City was to promote cooperation between IC3 and the industry. It was for me a forcing function to get my head around crypto-currencies and smart contracts. I learned a lot. Unfortunately I cannot claim that all these concepts are totally clear for me yet; hence the asterisk in the title :-)

Nevertheless, here are some of my personal takeaways and raw notes from the event.

Bitcoin vs Blockchain

Unless you have been living in a cave for the last eight years (2008 is Bitcoin year 0), you have heard about Bitcoin, the cryptocurrency living on the Bitcoin blockchain, managed by no central entity and used mostly by evil doers on the dark webs. Not to mention what we still don't know who hides behind the mysterious Satoshi Nakamoto, Bitcoin's inventor.

But Bitcoin is just one application of blockchain technologies. A blockchain is a public ledger of all transactions that have ever been executed. New transactions are added to blocks that are added to the blockchain in a linear, chronological order, following a complicated protocol where nodes compete against each other. The blockchain has "complete" information about the accounts and their balances right from the beginning of the ledger.

One intriguing aspect of Bitcoin is that Bitcoin is built on top of the Bitcoin blockchain, and the blockchain relies on Bitcoin itself for its operations (nodes compete against each other to earn some bitcoins). See [10] for a more detailed explanation.

Bitcoin as the most extreme version of a blockchain

Let's take a little detour and think about NoSQL databases. You want to store key-value pairs on an arbitrary set of nodes distributed all across the network. The way it usually happens is that a key is mapped to N nodes and these nodes will store the data. The data first goes to one node and some replication magic happens. This is not trivial to implement, but conceptually it is simple to understand.

To make things now a little spicier, let's assume that (a) nodes can come and go, (b) some nodes are rogue nodes and will not read/write the correct data, (c) each node owns a private key and uses heavy duty crypto for all communications, (d) storage and computation need to be paid for and (e) each node needs to run all transactions, group them into a block and solve a very expensive riddle to have the transaction approved. Your NoSQL system now looks way more complicated to understand and to run. And I am not even telling you that values may actually contain stored-procedures that can be executed across the entire network.

This is what Bitcoin, the Bitcoin blockchain and their descendants (e.g. Ethereum) are about.

Blockchains not all born equal

There are lots of design decisions one can make when building a blockchain.

In permissionless blockchains (e.g. Bitcoin), arbitrary nodes and join and leave the network. In permissioned blockchains (banks are going in this direction), nodes are vetted entities.
Blockchains can also vary based on their consensus algorithm, their block size, the topology of their network, etc.
Some blockchains focuses on pure ledger functionalities. Some offer smart contracts, i.e. arbitrary code running on the blockchain.

IC3 research challenges for the blockchain

Now let's go back to the workshop.
In a recent blog post about the future of AI, I was asking the following question: « What’s the “self-driving car” for my field of research?» For the field cryptography, I think that the answer is clearly Bitcoin, with lots of funding, press coverage, hype, interesting problems and interesting research ranging from hardware, distributed system, to cryptographic primitives, etc.

The organizers of the workshop presented 5 main research challenges.

  1. Scaling & performance
    Current blockchain technologies offer high latency (11 min for the Bitcoin blockchain) and low transaction throughput.
    How do we improve performance and reinvent consensus?

  2. Correctness
    Like most software engineering projects, the blockchain is not immune to bugs in code and protocols.
    How do we make it easy for developers to produce secure code and protocols, e.g. using higher-level programming languages and proofs?

  3. Confidentiality
    The main appeal of the blockchain is its totally transparent nature, being a public distributed ledger. This does not work for applications where confidentiality is key.
    How can transparency be squared with confidentiality using cryptographic or trusted-hardware approaches?

  4. Authenticated data
    Smart contracts living on the blockchain will rely on external data sources, e.g. stock feed, sports results, etc.
    How do we create an ecosystem of trustworthy data feeds for the blockchain?

  5. Safety & Compliance
    Smart contracts living on the blockchain will have to follow some form of regulation and will require monitoring and possibly targeted interventions.
    How do smart contracts handle compliance with existing legislation?

I will add two more challenges.

  • Challenge #0 is about a clear understanding of what the blockchain is.
  • Challenge #6 is about finding some concrete and useful applications of blockchain technologies, beyond cryptocurrencies. There are lots of ideas in the air, but the jury is still deliberating.

My 3 wishes for the blockchain genie

I still believe in magic lamps and genies. And I am pretty sure there is at least one genie living somewhere inside the blockchain.

Wish #1

My first wish is for a high-level domain specific language for smart contracts.
On the Ethereum blockchain, a smart contract is represented as a sequence of op-codes for a stack-based virtual machine. The Ethereum ecosystem provides two alternative languages to describe smart contract, one Python-based called Serpent and one Javascript-based called Solidity. Unfortunately, both are very error prone, as shown by [6]. If the blockchain is a database, we need to model it accordingly, define the right primitives and a declarative language à la SQL. Pushed the extreme at the UI level, I would envision a visual language like scratch, where a "safe" contract can be created by simply moving blocks. Pushed the extreme at the semantic level, I would envision smart contracts written in Coq (with proof associated with them) or in a flavor or Haskell or OCaml.
Not only you want your smart contracts to execute as advertised, you also want them to execute efficiently as executing a smart contract costs money. A highly optimized smart contract (with a few instructions shaved here and save) can save a lot of money if executed millions of times per day.

Wish #2

My second wish is a modular architecture for blockchains.
One major realization from the workshop is that the blockchain is a continuum along multiple dimensions and there is room for an infinity of blockchains, each optimizing for a slightly different use case. But all these blockchains are built using similar primitives. Taking some inspiration from unikernels (MirageOS in particular), the idea is to be able to instantiate a blockchain by gluing together various components into an edifice that provides some agreed-upon guarantees.

Wish #3

My last wish is for inspiring applications on the blockchain.
Crypto-currencies were the genesis of the blockchain. Financial applications now seem to be taking the lion share, mostly for transaction reconciliations. Smart contracts are clearly the next frontier where pretty much anything could be encoded, from a lottery, to an organization itself (the DAO). My personal inclination is more towards a civic application of the blockchain1. For instance, what would a blockchain for New York City mean? Better transparency for citizens, faster procurement, better financial exchanges across agencies, …


As mentioned in the introduction, there are still lots of elements of blockchain technologies that remain mysterious to me, especially around smart contracts. I will provide some follow-up to this post, as clarity starts to emerge.

In the meantime, the IC3 website is a really good source of information.

Stay tuned thirsty.

Selected quotes from the event

« BB = before bitcoin; AB = after bitcoin; year zero = 2008. »

« The blockchain is a database technology for players to mutualize. »

« It takes 1ms to make a trade, but 3 days to transfer the money. »

« Mining represent 98% of the bitcoin money. This is interesting to look at a system where 98% of the money is spent on defending the system against attackers. »

« It remains unclear how to replicate the bitcoin success. »

Some relevant resources

To follow

To read

To play with

  1. here is a recent announcement for an open­source, self­-sovereign, blockchain­-based identity system.