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

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

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 >

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

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.

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

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 .

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