1. Ironwood: A Correct-by-Construction Blockchain Protocol Implementation (Work in progress)
Good afternoon, everyone. I’m Haobin Ni from Cornell University. And I’d like to present Project Ironwood: A correct-by-construction blockchain protocol implementation.
This work is advised by Greg Morrisett and Robbert van Renesse and it’s still work in progress.
Haobin Ni, Greg Morrisett, Robbert van Renesse
Cornell University
May 10, 2018

2. The Trust We Need User Centralized Server
Let’s begin with some bed time story: back to the eighties, you were using the centralized services such like a bank or an exchange. Everyday you keep telling yourself that you will be good since you trust those services to be honest and they won’t turn against you.
User
Centralized Server

3. The Trust We Need Neptune Coin User Miners > For land on Neptune!
(No it’s a gas giant)
But now we have got bitcoins ethereum and more importantly, blockchains. So instead of assuming that the centralized monopoly will play nice, you put your faith in that most nodes out there are in the mining pool honest which sounds much more likely to be true.
However, there is still something missing in this picture. You are additionally assuming that the protocol implementation of the service you are using is also sound. Unfortunately, this has been shown not always to be the true.
User
Miners
>

4. The Trust We Need
OK, tell you what. We are open-sourced, use secure hardware with military level crypto. We have bug bounties and our WP even comes with a proof…
If we look further into how this trust in the protocol and its implementation is established, we will run into the conclusion that this kind of belief is actually established through a rather informal process:
The developers of the Neptune coin will tell their users and potential users that … all for the purpose of creating that kind of belief in their Neptune coin.
But the fact is this: just using a bunch buzzwords to describe it will never make the code more sound. In contrast, a rule of thumb is that the more features you have the more complex is your system; the more complex is your system, the more bugs will be in there.
Neptune Coin
User
But using a bunch of buzzwords will never make the code sound

5. Formal Verification
A mathematical proof on the properties of the program behaviors
For the code that gets executed
Machine-checked
Old vs New:
Believe in the implementation of the protocol
Believe in the implementation of the proof checker
Provides a much stronger guarantee on the reliability of the program
So how can we make sure those protocols we are using everywhere are correct down to the level of the code? A nice try would be trying to write a proof on the properties of the program behaviors for the code that actually gets executed.
One can imagine the size of this proof would be comparable to the size of the program, so it ought to be semi-automatically generated and machine checked instead of manual inspection for pen-and-paper proofs.
As a comparison, in the old world, you have to believe the implementation of the protocol. For example, the Neptune.
With formal verification, you only need to trust the proof checkers, such as Nuprl, Coq, or Z3.
I have many reasons to convince you that you’d be in a safer position for the latter case. These proof checkers are much smaller than a whole system to be verified. And they are time-tested by many independent users, you can also check the proof on your own machines. They are even developed by a separate group of people from those who developed the service you are using.
So overall, formal verification can provide a much stronger guarantee on the reliability of the program.

6. Methodology Overview
Project Goal: a formally verified blockchain implementation
Protocol Complexity
Realistic
Blockchain
Abstract Consensus Protocol
Abstraction level
BFT Protocol
Ideal Blockchain
So here I’d like to introduce the high-level methodology we are following to develop the system. Our goal is to build a formally verified blockchain implementation.
And we are starting from something nice and simple such as an abstract consensus protocol. Then we are moving forward both in the direction of protocol complexity to reach a realistic blockchain protocol and down in the direction of abstract level to get actual executable code.
And in the process, we plan to take more than a few steps such as an BFT Protocol and an ideal blockchain to get the destination.
Verified Executable Code
Executable
Program

7. Current Status
Abstract Consensus Protocol
Verified Executable Code
Abstraction level
Protocol Complexity
Realistic
Blockchain
Executable
Program
Ideal Blockchain
BFT Protocol
Current Step: Implementing a formalized BOSCO* Protocol in Coq
*BOSCO = Byzantine One Step Consensus Protocol
We are here!
And in terms of for current status, we are still in the very early stage of development. Conceptually, we are very close to complete a BFT Protocol. In the current step, I’m implementing a formalized BOSCO Protocol in the Coq proof assistant. By implementation I mean both the protocol itself and proof on the properties of the protocol. And BOSCO stands for Byzantine One Step Consensus Protocol which is a nice & simple consensus protocol .

8. Questions? Fig 1: An Ironwood Blockchain
For the last slide I’d like to show you a photo which remotely resembles how an ironwood blockchain would like. Any questions are welcomed. Thank you!
Fig 1: An Ironwood Blockchain