 So using formal methods is all about using techniques that are well founded in mathematics so that you can be reasonably sure that you don't mess anything up, that you can prove that things are correct, that you can reason about them formally and exactly and that you can also communicate about them, that you can have an expression of them in a very formal succinct mathematical language so that you can talk about them, reason about them and make sure that there's no mistakes in there. And we're using those in IOHK because we have this great team of researchers who are writing papers and designing protocols and proving properties about them, making sure they are correct but then we have to make sure that none of this correctness and of these assurances get lost as we go from the paper which is written in a human readable language in order to allow the researchers to communicate about them, that nothing of the correctness gets lost as we go from this language to something that is executed by a computer so that does not have any room for ambiguities or for some background knowledge to be inserted implicitly and that also covers many details that are irrelevant to the protocol as such such as things like networking, databases and stuff like that. And the way that we are using this in IOHK is that we first of all translate the protocol into a language that is exact and ideally already executable by a machine without ending any details so that it's possible for individual people to just read the paper, read the specification of the formal language and then ensure that those two are correct and then going from there and adding refinements, adding details and working towards something that is a full production code but is still related and ideally provably related to this original abstract formulation of the protocol. So after we've done this we basically have two implementations of the protocol or rather a series of implementations of the protocol, one at the top which is very abstract and which is easy to reason about and which you can basically verify in your head that it does match the description of the protocol. And then on the other end of this tower you have an implementation that is that runs in actual production that you cannot keep in your head all at once and that has all of these details that deal with the real world. And so one thing that we gain by going this way is that we make sure along the way that all the steps that we do are small enough to be certain or to be reasonably confident that they are correct but the other thing that we also gain is that we have a reference implementation that lacks all the details but that we are sure that is correct. And so we can also use that to test the real implementation. And this is actually what we are learning in this training of how to do. So we have John Hughes here who invented a quick check which is a framework which originally was implemented for Haskell but now exists in many languages and that allows you to do property based testing. So what that means is that you don't just write down individual test cases but you specify properties that you expect your system to obey and then quick check will generate lots of test cases and try to find a minimal one that breaks your system basically. And these property based tests are very suitable for comparing the reference implementation and the actual implementation.