 Dr. Virgil Griffith and Vikram Verma will present designs for the L4 contract programming language based on Deontic modal logic. Hello, everyone. So we're working. Are we sitting down? You're going to sit down. Okay. So if you guys are going to sit down, so we're going to, I think we can go to our first slide. I mean, this is actually, so there's going to be a lot of math in this talk, just like accept it. Where's our slide? Well, okay. We'll tell you in the meantime. So we're here to tell you about, we're developing a brand new language for contracts. And so it's sort of from a company called Legalize. Legalize.com. Legalize is an open source project with delusions of one day being a start-up. And so originally, so you can talk to us all there. So I'm kind of like the face and Vikram here is the brains. So we can just go ahead and go on straight and we can go to the next slide. And we'll tell you about the gist. Is there a clicker? Oh, okay. Wait. Buttons. Okay. Great. All right. So yeah. So we are giving you a lovely start-up here. So originally, our goal was to make a little programming language for lawyers to use. So the idea is that you would write your little contract in a little high-level language. The compile button, and you would get an English legalese out of it. And that was kind of like the big idea. And so I was friends with Vitalik over here, and they were doing even more sophisticated things with formal verification. So there's a nice joke. The joke is what do you call runtime debugging of a smart contract? And you think about it. And the answer is litigation. And you know, yeah, I know, I know. It's funny. But no, it's actually totally true. And basically it means that if you're going to have your smart contract, having runtime errors is like crazy expensive. And basically you just can't have them. So you're like, okay, well, how do we do it in other industries, like say hardware or space shuttles, where, you know, runtime errors are like just not okay, because you lose like a billion dollars. So yeah. So you do lots of formal verification. And so we're like, oh, well, let's go take all of our stuff for lawyers and give it to you, to give it to you, Etherians, because you're probably going to be our power users and you need it even more than the lawyers do. So yeah. So here we are. So we're making a custom DSL just for, you know, permissions and obligations. Surprisingly enough, some of the lawyers are actually already biting into this. You know, we said it's going to be technophobic. But hey, some of them actually get it. And so this is like, you know, a real offer. And they use some of our code. So oh, wrong button. Okay. So this is just kind of a BTDub. So the red is what we are modeling here, sort of all possible contracts. And then we have the dApps. And then we have the purple is where we can help you out. So our ideal world is where you'll write your little contract and you won't even think about Ethereum. It'll just be, oh, there'll be these agents with these obligations, blah, blah, blah. And then it will just compile. And you can, for the most part, just not worry about it. And in the future, you can even get your English contract as well. So okay. So let's go this one. Okay. So first people ask, well, we love Solidity. Do we really want another language? And the first answer is, oh, well, you can still have your Solidity. And if you still want your low-level stuff, you should still use Solidity. You can kind of think of it as, say, using, say, C versus, I guess something like Python, I suppose. That's not quite exactly right. But anyway, the idea is that you want like a high-level language for doing high-level things and you don't want to think about the rest. But if you're doing novel things and you want to be close to the bottom, then you should still use your Solidity. So we use SQL. Sort of an example for why it's a good idea. So you can imagine querying your database in C or JavaScript would be very unpleasant. But doing it in SQL is lovely. So we're going to give you an SQL for contracts. Okay. Yeah. So that's why you want to do it. Yeah. And the cool part about this is that, so the reason you don't want to do this is because, so first of all, you could eventually one day compile your Ethereum contracts to English. And number two, we could eventually start getting normal, like normal lawyers using Ethereum because here's the cool part. Because the Ethereum system is more reliable than a judge's brain. So you're like, oh, so we say, oh, you can take all lawyers, you can take all your regular contracts you're compiling to English, but now you just run them on Ethereum and they're even more reliable and even more predictable. And they would be like, oh, my God, yes. And therefore, we bring, you know, like what, the $90 billion contract-grouching industry into Ethereum, which will make all of your Ether go up and that will make all of you happy. So this is our start. Go. So we have rough consensus, but not running code. And the rest of this talk is essentially going to be a fairly high-level literature review of ways of expressing agreements and ways we can reason about them and eventually ways in which we can compile those into code, which is interpreted in a way that preserves those semantics. I am budding wrong. So CL is a logic-based formalism for expressing contracts. And this is its syntax. You can read that as saying that a contract either indicates an obligation to do something, a permission to do something, a prohibition from doing something, the conjunction of two other clauses, or some contract become active dependent on some other action having been performed. And we can look at the structure of obligations where we have two parameters, C and alpha. Alpha is the thing you're expected to perform right now. And if you do not do that, then you have to fulfill the reparation clause C. That clause C can be the far-right clause, which is unfulfillable. And if you ever get to that point, you're in breach of contract. Actions are basic propositional variables, which can be either expressed in terms of concurrent actions, i.e., you do things at the same time, or you sequencing, you do one thing after another, or you do between one of two things. To make that concrete, here's an example of a fairly simple clause. This expresses that if you do A, you must then perform B. And if you do B, you must not perform B. And if you breach either of those commitments, then you are in breach of contract. And just to make some of the later slides more legible, we sometimes omit the residual clause when it is unfulfillable. So there have been several semantics that have been defined for this language. Originally it was equipped with branching semantics. And the idea is there is that you can reason about which expressions can be substituted for each other and the sorts of things they imply. For example, you can take an obligation to perform some action is equivalent to the prohibition from not performing that action, which seems fairly simple. We're going to be focusing here mostly on trace semantics, where the idea is I want to say that some sequence of actions is consistent with a given contract. You can read this as saying the sequence of performing A and then later B as a claim, rather, fulfills the contract that we sold before. There are sets inside that sequence to accommodate concurrent actions. And I seem to have misworded the slides, but essentially this satisfaction defined relation is defined pretty much as you would expect. If you are obliged to form some concurrent set of actions, then you should perform them or otherwise you must fulfill the reparation. If you are obliged to perform some sequence of actions, you should perform one and then the other or otherwise fill that reparation. And this sort of reasoning is enough to derive that claim we made before, if you'll admit the somewhat aggressive normalization here. So to show that if you do A, you must do B, and if you do B, you must not do B in rough sequence. Well, we know that the sequence A, B does not involve initially doing A, and so that clause is trivially fulfilled. And in the other clause, because we do A initially, we have the residual obligation of having to do B, and that's fulfilled by the second component in the sequence. I'm going on the wrong order. It's the other way button. It's the down button? Yes, the down. Thank you for the down button. So that's fairly well. But the cool thing about this particular satisfaction relation is it's decidable, and there's a rendering onto automata so that you can essentially just pass these things to this machine, and it can tell you whether you're in compliance or in breach or whether you have residual obligations which later actions in the trace may or may not let you fulfill. And the cool thing about these graphs, this is an alternating automata, but it doesn't have to be, but never mind because time, is that you can do a bunch of analyses about these which tell you properties about your contract. So you can say that the sequence AB satisfies it, and so does the sequence A, A and B, and so does the sequence BA because that validates in both automata. You can say further that it's satisfiable because there exists a trace which is compliant. Another interesting thing about this particular automata is that if you consider the sequence in which you initially perform both A and B at the same time, there's no valid extension of that trace. And so with respect to your standard trace semantics, that's probably fine, but we see something here. We see that at this coordinate, we have the diantech obligation to perform both B and not perform B, i.e. the contract is telling us that under some sequence that we have conflicting obligations, and this is somewhat undesirable. And so there was another paper which essentially extended the semantics to account for the diantech responsibilities at each coordinate and essentially assigned what patterns you need to fulfill in order to not have a conflict, and this should be true of all traces. You can render this into an automata, but you're mushing things together so that all the obligations are in the same place. And then you just pattern match on these to determine whether you're saying two things which you should not be saying at the same time. OK. So no, I need to thank you. Oh, you need the clicker thing. So this is the one that I liked best. So this one's a little neat because the previous one you saw, it gives a really nice flexible way of representing contracts. But when the shit hits the fan, you don't know whom to blame. And you're like, oh, you're always going to blame someone, right? And in particular, so this is a novel approach that allows you to say, oh, well, when someone doesn't do their job, it says so. And you can see exactly who that is. This is nice because then you could hypothetically etherealize judges. And this is the one where the lawyers would fully join us, and that would be great. So right now, the way things go is that you would write your things in a little contract. But when it goes awry, you still have to go back to the traditional legal system. So this idea is, oh, you have to go to the legal system at all because you know exactly who is to blame for every possible path through the contract. And that would just be great. So I'll show you roughly how it goes. So this button. So basically, there is a verdict, which is V. And there's two ways a verdict can go over a contract. It can be a check mark, which means everything's great. Or it can say there's a timestamp with a little tau, and there's a blame, meaning someone fucked up. And basically, in every contract is defined as a function that maps a sequence of events or sequence of actions sigma to either a check mark, meaning it's great, or a timestamp, and then someone fucked up. And yeah, and that's it. And so you can say, oh, well, OK. So you can fully describe the ways through a contract through all these different sigmas. OK. And you can do cool, cool, cool composition contracts, too. So you can say, oh, well, so you have contract V1 and V2. So you can and them, or you can or them. So that's a little operations there. And basically it tells you how they go. And you can do more interesting things. So you can say, oh, so here's probably the coolest one is to look at this application clause. So you have agent. So this is this. Oh, go back. There you go. So you have agent E1 executing these actions, K. And it takes parameters, x little thing over it. And so it's due within some little window D. And if it wins, sorry, and if it satisfies all of it, then it says, oh, there's still, you get time left, Z. So you have like five days to do something and you finish it in three days, Z becomes two. And then it goes on to the next contract. So you can sort of chain contracts together. In this recursive form. And that's like really neat. So it's kind of this idea, oh, so we're kind of doing the beginning here. We were doing sort of like what are the atoms of contracts? So I was like the periodic table. And these give you all different ways that you can chain them together. You can do a chemistry of contracts and make cool molecules out of them. And you can make that crazy shit. Yeah, so this says this is really fertile. OK, yeah, so here's an example one right here. So this is an NDA contract. So this appreciate board. So it takes one argument, the employee, and it says, oh, if you ever get a disclosure reported, when it takes an E. And if E is the employee and it's happened within the past five years, then breach. And that employee is at fault. And the little then employee says the employee as a blame. And it says, oh, and by the way, and it starts now. And in this little simple code, you can compile this to English in any arbitrary jurisdiction. You could do it in English, French, Mandarin, whatever, or Ethereum. And yeah, and it would all just work. OK, cool. So this is basically in here for the languages and math people who want to know how you actually implement these ideas. That's it. This is for you. And so there are some complications in the way that you can merge contracts. There are some restrictions. So for example, so you have different contracts, but the people who they blame aren't always the same. You can't combine them. And that's kind of a limitation. And that's annoying. And we should pay a PhD to figure that out. OK, so this is sort of the next one. This is how this connects to the upcoming literature, which we'll probably hear about probably tomorrow on specifically Ethereum. How much time do we have? Because the things say it's like 30 seconds. That's correct. I'm just going to skip to the next slide. And deep embeddings are cool. And we have a very well-defined idea in terms of the space of variation in the contracts you can express, what indicates good behavior. And the rest is basically relates to the compiler. And you want to be able to say that normalization with respect to a logic behaves equivalently in your source logic and in your compiled output. And we can do that and stuff. All right, last one. You have to hit it. All right, so this is the end? Oh, no, the other button. There you go. So OK, so this is basically our thing. So basically, we're here. So we are basically formalizing contracts sort of in the broad sense. We expect you, if you were thinking to be our power users, so if you want features, you should let us know because we're designing this. And yeah, and we'll do like free work for you. And if you're interested in this kind of thing, come hang out with us. And if you want to follow us, there's our mailing list and there's our email address. Yeah, come talk to us about languages sometime.