 So first of all, I want to thank Ethereum for inviting us out. This is the third year that I've been speaking at the Ethereum DevCon. And I think it's remarkably open-minded since RoLang is running on a completely different network. It's a completely different approach to contracting languages and a completely different approach in general to the whole blockchain architecture. So I'm really, really exceptionally impressed by the open-mindedness and the inclusiveness and that general principle within the blockchain culture. I think that's awesome. I also want to say that today is All Saints Day, right? Halloween is All Hallows Eve and today is All Saints Day. And I want to give a shout out. My 14-year-old son is here today. And this is sort of to all the young saints who are inheriting the planet that we're leaving them and what they have to face. And I think that the blockchain is very much about that. So with that, let me introduce RoLang. The message is going to be really simple. I'm keeping this, as I was writing the slides, I was thinking, I'm going to make this a super boring talk. So the aim is to be boring but clear. And maybe if we can figure out a way to have fun while being boring and clear, let's see if we can do that. So instead of hello world, let's do hello arithmetic. And I'm going to do the simplest, stupidest contract in RoLang. And I'll just walk you through that. And then I'll talk a little bit of, I'm going to introduce some nondeterminism into that contract and talk about how CASPER addresses the nondeterminism and the concurrency inside the language. And then we'll look at a more sophisticated contract. And I've actually got Kent Shikama here with me on Zoom. And he's going to walk us through the ERC-20 contract implementation that he's done. Kent joined us in the summer and took over the work that I was doing on the RoLang compiler and has done an amazing job taking it further and then writing sample contracts to test his code. So he did an example of an ERC-20-like contract in RoLang, which is running now. And you can go play with it. There's also RoLang.org, so you can go check out that website right now. And Kent graciously put up a video of this, the demo he's going to give today. So if you don't catch it now, you can also go back and look at it at your leisure. And then, so that's kind of the order. And then we'll talk about some other things towards the end. One thing that I will ask you to ask me about later is the behavioral type system. Right now we're going to be focusing on the untyped portion of the language, or we're just not looking at the types because you type the entire language. Because if you get the conceptual apparatus, the types are easy. Okay. So here's a simple, a very, very simple contract. It's actually a contract scheme because I've left some holes in the contract where you could put additional code. So this contract is very straightforward. What it does, first of all, it's parametric in a set of channels or ports. So if you heard Martin Beezy's talk earlier, so he was talking about port-based or channel-based computational models. So that's what RoLang is. In RoLang, there are basically only two things in the world. There are ports and channels, we use those synonymously. We also call them names sometimes, and there are processes that use ports, channels, names to communicate. Right? That's it. That's the entire ontology in this computational universe. So contracts are just processes that are parametric in some ports or channels. So this contract C is parametric in four channels. And it does a couple of things in parallel. So I'm going to stand over here. I like pointing at the screen. I hope that's okay with you guys. So one thread of activity waits at the channel X for something that it's going to call Y, and at the same time, it's also waiting at the channel U for something it's going to call V. And unless it gets both of those inputs in any order, but unless it gets both of those inputs, the rest of this doesn't happen, okay? And the rest, so you can see this as a kind of sequentialization. And this vertical bar here represents another thread of activity, okay? And this thread of activity waits at the channel Z for something it's going to call W and then does this. So in the top thread, the rest of the computation is to take what it received on Y and what it received as V. So what it receives as Y and what it receives as V. There's one tiny little piece of information you have to know, which is that whenever information comes in this way, it's treated as a reference. You could also think of that as a port or a channel, but it's treated as a reference. And so you have to dereference it. And that's what these little stars are doing. And we're kind of expecting that whatever we dereference, it's going to be safe to add those two things together. So this operation here has to be interpretable for these two different values that are being received at these ports. And then it's going to, whatever the result of that addition is, that's going to be sent on the Z port, okay? And then in parallel with that output operation, there's something else that might happen that uses X and Z, okay? Over here, it's a similar kind of thing. On the A port, it's going to take whatever it received on W, multiply it by two and send that out, okay? And Q runs in parallel with that output operation. Very straightforward. Nothing magical here. Easy to understand. And in fact, I've made a graphical representation of this same flow, okay? So all I've done is to map out graphically the lifetimes of the ports as far as we know, right? And you can see one thing that happens that's kind of interesting, is that Z is handed to two threads. So we can see this resource is being utilized by two different threads. Now in this particular example, you can also see something straight away that our compiler can also see. That even though there's a logical parallelism, there's actually only one thread of activity, which is that this is only going to activate if it gets something on Z, and there's exactly one thing that's sending on Z. So this is really a sequential flow, right? So there are lots and lots of things that you can see just by staring at the code. And in fact, that's what makes Rowland kind of cool. You stare at the code or you let a computer stare at the code, and it does a bunch of analysis for you. So in particular, if I remove all that pesky syntax, and just look at the graph that is evident in the flow here, I can see some really cool things. One is that every contract is actually just a braid or a tangle, right? Here's one set of strands, right? Sometimes the strands can fork, right? And there's another set of strands that weave across these that have to do with the information flow. Is this making sense? Let's make this as interactive as possible. If this doesn't make sense, shout out, I don't get it. Okay, and then so whenever we have a weave that goes like this across, that's a possible contention of resources. So we can see that in fact there is a tangle across this collection of names, right? And so we have to, and it literally spans the entire collection of names. So we can see that relative to this set of names, we have to make sure that transactions are ordered, right? We have to be careful about the order of transactions. Names outside of this set, we don't care about the order of transactions unless they touch this set, right? And we can actually see that, yes. Please, yeah, yeah, yeah. No, if you'll notice that this is nested inside this scope here, right, so it's blocked until you get both of them. Yeah, exactly. It's a graphical way of representing that barrier. Yeah, exactly right. Good question, yes. Yes, the vertical bar is here. That's exactly right. No, it's actually true, it can be interpreted as true parallelism. It can be interpreted as an interleaving or it can be interpreted as true parallelism. Thank you, that's a very good question. Awesome. Okay, so moving right along. So we can now make a test harness for this. So what we're gonna do to test this code, or to at least understand what it does, is we're gonna set P and Q to just be zero. Don't do anything, right, for this. And then we're going to make some fresh channels, right, that's what this new does. And we're gonna supply them to the contract. We're gonna supply them to things that could interact with the contract. Okay, so here is our input section which is going to input where at X and U. And here is our readout. This is going to interact with C at A. And whatever the result is, it's going to print that out. Is that making sense? Awesome, okay. So what you can immediately see from the code is that that will print out the resulting value of six. And that's immediate from the code, yes. Oh, thank you, that's a typo, yes. Good eyes, thank you, I appreciate that. So here is the picture of that just in blocks. So here's the input section. It's running in parallel with the contract. Here's the output section. It's running in parallel with the contract, right? And so the contract interacts with this test harness in this way. And there's the new scope that allows us to see the origin of all the channels. Is that making sense? Okay, so we have a nice clear graphical interpretation that allows us to just inspect the concurrency behavior of the code and just see what's going on. So let's move right along and introduce some non-determinism. We could see with our eyes that there wasn't any real non-determinism except at the edges, right? So there could have been, just to make that point very clear, there could have been non-determinism here if there were contending inputs, right? And there could have been non-determinism here if there were contending listeners for the output. But the contract itself, even though it has parallelism in it, is actually deterministic in its execution. So now what we do is we modify our contract and we add another listener on Zed, okay? And now these two are contending. And all we're doing is if this listener wins, you get an even value. And if this listener wins, you get an odd value, right? That's all that's happening. This is so boring. Why is this guy talking about this stuff? It's so obvious. So again, pictorially, we now have a source of non-determinism because this output can either line up with the input here or the input here. And that raises our interesting question with respect to blockchain semantics, right? How do you guarantee if I had many, many instances of this very same contract running, how do I make sure that they all win the race in exactly the same way? And that's the answer, okay? But I'll get to that in just a second because there's another important point here. So I can now generalize K, right? So I can generalize my test harness. And what I do is here's the test harness bit and that's where I put C before. So I make a K into literature of process-calculi usually and in fact in programming language semantics in general, it usually is used to range over contexts which are programs where you've knocked a hole. And in general, we want programs to be equivalent exactly when they behave the same in all contexts, right? So what I'm doing is I'm kind of sneaking in just a tiny little bit of programming language semantics on the side to keep the talk from being totally boring. All right, so here's the context with the test harness with the hole knocked in it. And now when I apply my test harness, oh these should have been commas. I don't know what happened there, sorry about that. When I apply my test harness again to C, we should get the deterministic six. When I apply my context to C prime, now we either get six or five, non-deterministically. So all I've done is just restate everything I said before in symbols. And by the way, what should be happening is in your mind you start thinking, huh, this notion of contextual equivalence should line up with things like, do my types ensure that my programs behave in a nice way. So this should be this nice correspondence between how the types constrained the behavior of my contracts and how the contextual equivalence or substitutability constrains the behavior of my contracts. They should fit perfectly. Why? So that if I were to do type checking, I don't know, maybe it would be the same as formally proving my programs correct. Why would we want to do that? Okay, so first I want to talk a little bit about what Casper is doing or what any consensus algorithm is doing in this setting. What the consensus algorithm is doing in this setting is it's guaranteeing that all the instances agree on the winners of the races. So the IO events are the only transactions, addresses as you know and love them become channels. This making sense? Right, okay, and then our consensus algorithm needs to just worry about those kinds of transactions and if you remember back to our tangle description it only has to order those transactions where you have these tangles and you can clearly see those. Right, you can actually automatically observe those tangles and see where you have isolation and then your consensus algorithm only has to worry about schedules or orders that make sure that things are ordered in the tangles and relative to two different disjoint tangles they can be in any order. Yes, yes, the short answer is yes. Okay, so effectively what we've just done is we've now related our computational model to scaling and it's not just sharding, it's actually compositional. One thing I didn't agree with in Martin's talk and I love this kind of debate and disagreement is Martin suggested he'd never know why or when you might break into more than one level. Well all you have to do is look at URIs or DNS. To begin to see why you would ever have more than two levels, right? There's lots and lots and lots of examples on the internet for why multiple layers of nesting is a good idea and if we grow and grow and grow, I don't know, maybe we have a Mars colony, a colony on Alpha Centauri, maybe the namespaces get even bigger. Ask me about namespaces at the end. Okay, so let me just quickly hang on one second because I've got to leave enough time for the demo. Oh yeah, yeah, so we started a little bit late but I'm gonna have to hold some questions because I want Ken to give some time to talk. So I'm gonna quickly just reiterate what I said and then move into the next part of the talk which is a more realistic contract and a demo. Okay, so yeah, the important point is that consensus ensures that every VM agrees on the winner of the race. That's the computational model here. All right, so now let's have Euclid take a look at ERC20 and see how that works. So I'm gonna see if we can get Kent on the screen here. Kent, are you there? Awesome, so I don't know if the audio is coming through but if not, I'll just hold the mic up to the device. So Kent and I were talking last night, we didn't hang on one second, I just want to introduce you. There was a miscommunication on when the talk was so that's why he was supposed to be here physically present. He's not flying in until tomorrow so we're gonna give him a chance to go through Zoom. So let's see if this works. Now go. Send a message in which you will listen to see whether the transfer succeeded or not. And so again, we have a fourth statement here that balances this year and we create two new channels and this is in order to essentially get the party for the balance of the message sender and the address sending it to. And then in the match statement here, check some preconditions and essentially here we're checking the balance of the sender is greater than the amount they're sending. The amount is greater than zero. Finally, there's just the overflow check. This is equivalent logic to the solidity implementation. And so if the preconditions succeed, we go into this case and in this case, we simply update the map such that it reflects the appropriate balances post-transfer and then we return true on the return channel to signify the transfer succeeded. And if the preconditions fail, we go into this case in which we update the map into the balances channel and then sending false on the return channel to signify the transfer fail. Is there any questions so far? Sorry. Any questions so far? Sweet. Okay, go ahead. So then just to show an example. Oh, makes what bigger the font? Oh, can you make the view bigger, Kent? Sure. Okay, so is that good? Is that better? Okay, we got a sense here. Cool. So here we're instantiating the token with me as the owner, so to speak, 100 as the initial supply and return as instantiated here as the channel that we're gonna receive back the map from. And so once we bind the result back into the token contract here, we can retrieve get using this get call as an area index into the token contract and we get the transfer channel and then we send from me to they 50 tokens. And so the point I think they understand here is that the name of the nested transfer contract that I just described here is not actually globally accessible. And so what we're doing here with this area index is we're actually going into or we're having the transfer name here be returned out of the token contract so that it's accessible from the outside. And so we have this like nice scoping kind of thing going on here. And so I mean, just back to line 100.2 we just do the same thing by we call the balanced off this queries for the balance and then we just print it out here. And this stuff here is essentially doing the same thing. I just wanted to demonstrate that you could do this or you can instantiate multiple tokens in parallel within the same session. And so we currently have a compiler really big Scala using BNFC, JavaCup and JLabs. And so on the bottom here, I have an SBQ console session and I'm just going to run the compiler on the token contract cloud that I just explained here. And so boom, we see here the output. And so what you see here is called RBL, Rosette Base Language. And in the future we plan to just bootstrap rolling but for now we find it convenient just to compile it down to this intermediate language because there's a nice VM for it which or an interpreter, I should say, right here. It has maybe an unusual syntax but it's just like any other interpreter. And so what's important here is that what we're interested in here is pasting in the compiler output of the token and that's what I'll do right now. Actually, one second. Let me just, one thing I have to do is I have to break the output up mostly because of the Ripple's maximum input length requirement. And so once we do that and we copy it in you can see here, this is what I just copied in. This is equivalent to the output here. And if we ignore some warnings and debug statements, we can see here the value 50 that gets outputted in 500. And so what these two numbers are correspond to the print statements here, right? Remember we transferred 50 to Bay so they should have 50 and in a way Bay balance two should have 500 because that's what we transferred over here and printed it. And so that's essentially the Relang demo of the EOC 20 contract in a nutshell. Thank you, Kent. I really appreciate that. So obviously you can see that this is work in progress. We're in the midst of building this. Let me quickly just close this out because I know I want to yield back time if I can. Okay, so what you saw was a side by side comparison of ERC 20 like behavior in Rolang which gives you a sense that the language scales up. It scales up why? Because it's at least as expressive. They're more or less the same line count but you get all of these features that we talked about before. So the things that we haven't talked about and I would love for you to come up to me and talk about after in breakout sessions and other kinds of things is the behavioral types. So I kept hinting that we can just look at the program and start to see things like sharding and concurrency kinds of opportunities or behaviors. The behavioral types catch that at compile time. So for example, the Dow bug we would have caught at compile time. The principal bug that caused the problem we would have caught before the code was ever checked in. Namespaces, our ports and channels are describable because they have internal structure. They're not just flat addresses. They're actually paths or algebraic. There's an algebra on ports. And because of that, we can describe sets of names so we can constrain it that way and that gives us a sharding solution. Rose Scala is what plugs the gap that you saw there where Kent was compiling to RBL and then pasting it into a Rosette interpreter which uses the Rosette virtual machine. So the Rose Scala is the Scala re-implementation of the Rosette virtual machine which would allow Kent to directly feed that code into the VM and execute it. And then also, please come and talk to us about our chain itself which is where all this work is happening and we're very...