 Hello everyone. I'm Fabrizio. This will be a talk about compositionality. It's probably a word that not all of you know, and I'll try to explain what this is about in the course of this workshop. In the last months, probably a year or so, we've been hearing a lot about composable things, composable blockchains, composable service. Compositionality is basically just a mathematical structure theory that tells you how to do that in the most principal way possible. I'll start and if you have any questions, just feel free to raise your hand and interrupt me and I'll try to answer and or clarify. First of all, to introduce the concept of compositionality, we need to introduce some basic building blocks that are systems and processes. Compositionality is basically the study of how systems compose to give life to more complex systems. Systems are basically things that can be transformed and acted upon. And processes are exactly the things that act on systems and transform them. A very interesting insight from modern mathematics, so the mathematics developed from 1950 onwards, is that often it's way more fruitful to understand something, to describe it by looking at how the thing composes and behaves in a context. So instead of splitting things open and look how they look on the inside, we describe them by saying how they behave and how they interact. Okay, so let's start with something very, very simple. I will use a lot of pictures in this talk and hopefully close to zero mathematics. For people that love mathematics, I can add that there is a soundness, a completeness theorem that says that these pictures are formal, which means by doing pictures we're actually doing mathematics, it's just easier and more beautiful, in my opinion. So in here we have a very simple process that we depict as a box. It just takes a number in input, adds one, and spits a number as output. I mean for, I guess, everyone acquainted with programming, that's just like, yeah, okay. The point is that when we have a process like that, we can compose it with other processes. So for instance, in here we take this process, we notice that it needs an input that is a number and spits out an output that is a number, and we realize that oh, we can actually pipe this process with itself, and if we do that by just concatenating the boxes, you see that this will be equivalent to the process that adds two to your input. Now, this seems very naive, but the nice thing about this picture is that it goes both ways. You can start from the top row where you have simple components and you actually abstract away, so add two is basically just the dotted box encompassing the two, or you can do the opposite. You can start from a process, add two, and open it up and further specify it with a finer degree of accuracy. And since you have an equal sign, you can basically go both ways. Now, there are very peculiar processes that are called identity processes. These are the processes that don't do anything. In this case, with the number example, we have a process that is at zero that takes a number and input, does absolutely nothing with it, and spits the same number as output. The good thing about graphical reasoning is that since this thing is not doing absolutely anything, we can just not draw it. And indeed, I'm drawing it as a dotted box down here just to highlight that there should be something there. But with this very simple trick, we can already start proving some equations that are very simple. So if I add one and then I add zero, it's like just adding one, right? If you adopt the convention of not drawing identity processes, then the picture on the top row just looks like the one in the bottom row while you have stretched a wire a little bit more. Similarly, I don't have it here on the slides, but you can understand that in this formalism, the composition is associative. We don't use parentheses. If you concatenate three boxes one after the other, it doesn't matter in which order you obstruct them. In the end, you only have three boxes, so it doesn't matter how you group them. Okay, let's do another example. So for this example, I'm using gravitation. Gravitation that has absolutely nothing to do with crypto, I admit. At least I think, I don't know, maybe. So we have a system that is a sun that is just sit there and does nothing and raise the earth that is orbiting around the sun. So during many centuries, people thought a lot about this and at some point basically a guy called Newton found out that there is a process that you can call evolve in which you can feed a state of your system and then you can say, okay, show me what happens one second later. And this is a beautiful predictive power of physics, in this case of dynamical systems that allows you to start from some experimental evidence and predict what is going to happen in the future. You see that in this example, you also have an identity process that is the process that doesn't evolve, evolve for like zero time, it's just taking the input and it's not looking in the future or in the past, it's just giving you the state as it is now. And we see that we have a notion of composition because if I let evolve the process for, I don't know, one second, I go from the position marked T0 to the position marked T1. Again, I can feed T1 to the system another time, let it evolve for another second and I go to T2 and that would be the same of evolving the system for two seconds. So again, I can combine these bricks. Now, the important thing is that anything that matters, everything that matters in this formalism is how things are connected. You can deform the wires, no problem. What you can't do is you cannot make new connections or splitting connections. If you do, you are getting something that has a different meaning. Another important thing is that you can only compose things with matching types. For instance, senior, I have the HUB1 process. We saw that that spits out a number, but the evolved thing wanted something of type sun, earth as an input. So you see that it doesn't really make sense to compose these things because they are apples and pears. Okay, so these tells us that types in this formalism are very important. The way you type your processes changes what you can and cannot compose. Okay, as an example, imagine that you have a car, right? You have the wheel and the shaft and the gas tank. And you could see this as a process that takes some inputs. For instance, I don't know, fuel and human action and produces heat and motion. But when you look very carefully, you see that you could pour any liquid in your car, right? Like the gas tank won't complain if you fill it with water. Clearly the engine will though. And basically from this you can infer that the problem here is that the type of input of our process is too general. And it allows you to fiddle with the process in a way that produces unintended behavior. Another example that I like is imagine a socket in the wall. You can put a plug into it and use any electronic appliance. But if you have a couple of nails, you can also stick the nails in the socket. And what you get is emerging behavior all over you and very painful. So the important thing here is this is the main message of compositionality. So when you look at this process, like the socket and plug process, you can start asking what are the properties that are preserved when I compose these processes together? So physically sticking the nails in the socket makes total sense because they fit. But if you are looking at things through the lens of safety regulations, you see that a nail can be safe, can be certified with whatever standard your country has. Same thing for the socket, but when you compose them, suddenly you have a very, very unsafe system. Compositionality is exactly the art of choosing these types in a way that emerging behavior is averted as much as possible. So that when you compose things, you know precisely what we are going to get. Now under the hood, compositionality is based on a theory called category theory. This was invented in 1942 and had a monstrous impact on modern mathematics. Essentially you can see it as a superglue of mathematics that describes how different theories compose and interact. Basically all the main progress in big areas of mathematics like algebraic geometry or algebraic topology come from here. And in the last year people started realizing that this thing can be applied also outside of mathematics because again it embodies this perspective that you can describe things but looking how they behave in a context. So when I show you those diagrams, what I'm really doing, I'm always picking a category that defines the universe I'm working on and working in. Let me just dig a bit deeper into this idea. So if you want to define a category, if you're a mathematician and you want to define it formally, basically you have to specify various entities. You have to specify objects that correspond to systems in the pictures I showed you before. So objects would be the wires in the box and wire pictures. You have to specify morphisms that are the process, the boxes that transform objects into objects. You are required to specify identities. So for each system you need to have a process that doesn't do anything to it. And then you basically have to specify a composition law, a recipe that tells you what happens when you compose processes together. Let me give you some examples of categories that are probably familiar to, I hope as many people as possible here. There's a categorical set where your objects are sets and your morphisms. So your processes are functions between sets. There is always a function that doesn't do anything and you can pipe functions into each other. For programmers, there is another category called data where your objects are data types and your programs are programs that turn data types into data types. Again, you can compose programs. This is basically functional programming style programming. You can pipe the output of a program into the input of another program if the data type matches. And you have also a program that just returns the input without doing anything. So what is the difference between these two categories? Well, set offers an intentional, sorry, an extensional perspective. What it means is that, for instance, if I consider the set of integer numbers, I have exactly one function that takes a number and adds n to it. On the contrary, in data, I have multiple ways of either specify what integer numbers are and I have multiple programs that sum n to your term. In here, I just wrote two of them. But in general, you see that in the category data, the formalization, the implementation matters. So these two categories offer very different views on the same phenomenon. In one case, you're saying I'm only interested about behavior. I'm not interested about the inner workings of these functions. In the other one, you say, no, I do. And I distinguish two processes. They could emit the same output on the same input, but I want to keep them distinguished. So the cool thing about category tier is that you can connect these different perspectives. There is a notion called functor that turns the category into another category. In our framework, this would be a box that is sort of like level two box that allows you to change the universe you are working in. So basically what you do to define a functor is you specify the mapping from the object of the category C to the objects of the category D. So you have to say where systems of C go in D. You do the same for the morphisms. So for each process in C, you have to map it to a process in D. And this is the important thing. These mappings have to map identities into identities and compositions into compositions. So what it means is that if I compose two processes in C, and I use the functor, it's the same of using the functors on the components and then composing them in D. Questions or? Sure. Not necessarily. You can have functors that are called full and faithful that allow you to yet basically be inverted and go one direction to the other. But no, in general these can, you can lose information or you can embed a less expressive universe into a more expressive universe if you want to. Sure. Sorry. Functors has information. Oh, linear transformations. Maybe. I don't know. There is this very convenient thing that in category theory everything is everything else. I'm not going in depth into that, but you can describe a category as a functor and a functor as a category and blah, blah, blah. So it is possible maybe to describe a functor as a sort of linear transformation. In general what I can say is that you can define categories of vector spaces for instance and in that case your morphisms, your systems will be linear applications that respect the linearity of the vector space. Yeah. Yeah, yeah. This is exactly what happens because this thing is basically mapping processes of C to processes of D. So you can see it as an higher level function and indeed a functor is a process in the category of categories. So you can do this kind of level up. Let me give you an example of functor. This is a functor that actually collapses information. We saw two categories, data and set, and we can define a functor that sends a data type into the set it implements and sends every program to the function it implements. So this is exactly what I was saying before that you can start in the category data and be very detailed about distinguishing things and then you say actually I don't care. I want to collapse all this information and I want to forget about these different details. You apply this functor and that's exactly what you get. All your process compositions now lose a part of information. Obviously there are very interesting questions like how do I invert these things? Is there a procedure to canonically invert a functor and actually go for instance from just a specification to sorry from a behavioral extensional perspective to something more complicated? Sometimes you can, sometimes you can. Yeah, so imagine that int is a data type that you define, I don't know, in Askel about integers. That data type is basically modeling the set of integers in a computer, right? So conceptually you can say I can send that to Z. Similarly, if you have the data type string you can have a set of all the possible words on an alphabet and again you can send string to that set. With this functor basically what happens is that these two programs here get mapped to the same function between sets. So I have two different implementations of the same program that maybe I consider separate as programs. Like if I for instance hash the one on the left and the one on the right the hashes will be different but they correspond to the same function. They are implementing the same function. So when I go from data to set I'm deciding willingly to lose that information. Okay, let's try to use what we got up to now to do some process design that is actually the interesting part of it. This is a very simple example. Imagine that you have a grid and you want to define the process of moving on this grid. So imagine that you can only move of, you know, a kind of fixed amount of things so it's not like I cannot move like 0.1 steps but only one step at a time. In this case you'll see that wherever you are there will be four fundamental processes that are up, down, left, right that allow you to move one step and now I can basically describe every path as a concatenation of these processes. So for instance if I move three times right and two times down I'm describing the L path I have there. If I feed to this process a couple of coordinates that tell me where I am then these coordinates will be transformed as in the end of the path basically. And we see that in this kind of theory we also have some equations like if you move right and then down that's the same of moving down and then right. You are describing a square you are just walking in like different paths but you end up in the same place. Let's spice this up and let's do it concurrently. Now we have multiple agents wandering on this grid and we want to model you know how they move. Intuitively what you do is well now we want to consider processes that happen in parallel like if I have two agents for instance I can have this process here that says agent one moves three times on the right and agent two moves down and then on the right and now we see that new equations pop out. So for instance I have this equation here called the interchange law that basically says these two threads are separate. You can see the first is saying I move somewhere and then I do nothing. The other agent does nothing and waits for you to move and then moves. In this setup is the same if you just you know swap the things and second agent moves first and first agent moves later. Why? Because intuitively these two agents are not causally interfering with each other. Agent one doesn't care at all about what agent two does and vice versa and so in this formalization of moving on a grid concurrently I have these extra equations. Mathematically we say that the universe we are relying upon is not just a category but it's something called the monoidal category. That basically means a category where you can do also things in parallel. Okay let's do a more like programming oriented example. So let's consider a very simple record. Let's call it person. This record has two fields name and surname okay. Now you can notice that in this record in this example person is basically just a couple of terms of type name and surname. Now we want to be able to you know functionally describe the procedure of extracting a subfield of this record. So you give me a person I give you the name for instance and we also want to be able to replace the subfield of a given type with a subfield of a different type. This is a bit more complicated but what it really means is that for instance imagine that I want to edit this person record I want to strip surname out and put a new field in called age. That is of different type. So the point is how can we do that in an automated and more importantly compositional way. So what I mean by compositional is imagine this example where I have the record person but one of the fields is itself a record is a sub record. And now I say okay I want to replace the city thing there Bogota with something else intuitively I want to be able to pipe the process for editing person with the process for editing address and you know feed these compose these two processes in a way so that I don't have to reinvent the wheel every time. The way you do this in functional programming and in compositionality is with something called a lens that is a particular example of something called an optic. So what is the idea? The idea is that a lens is just a couple of processes one called get and one called put and basically get is taking your record and is giving you the subfield that in this case is s subfield of a what put does instead put is taking your record a is taking something of type t and intuitively is replacing s with t and now is spitting out something of type B you see the type of a could change because you replace the type of a subfield of this thing if a was a couple of strings with this put I could substitute a string type with a nint type and then the overall type of the record will change. The funny thing about this is that you know there is an ask a library for instance that allows you to automatically get these things for every a s and t as soon as you define your type a this thing will you know create the setters and getters automatically for you. So it's a procedure that you can automate and that's the cool thing you don't have to do it manually the library does it for you. Okay so how do these things compose imagine that I have two lenses so the first is taking the subfield s from a and the second one is taking the subfield v from s the get part is easy because you see you can just telescopically access the records you can say I start from a I pull out s and I pull out v from s the put part is a bit more complicated so what happens here is that imagine that in s I am replacing the subfield v with a subfield w and I obtain something of type t and now I want to replace s with this type b into a how do I compose these two things well with this sort of like monstrous awful thing here in in the bottom where I basically take a I copy a I get s from a now you see I can use this put v and basically substitute v in s with w I get something of type t and then I can use put on t and a to get a b I know that this sounds very cumbersome and difficult to follow but a good thing is that you can you know topologically deform these diagrams and basically express them in a way that makes way more sense so in here instead of considering these things as two couple of separate processes I'm you know packaging them as a unique thing so as you can see this thing is a bit strange because it has arrows going in opposite directions so on the top row a gets processed into an s so you are extracting s from a on the bottom row you are getting this t on the right and you know you are writing s with t and you are getting a b on the left this is an example of a bimodular data accessor the way you can think about it is as a process that says if you give me an a I will read field s and forward the output to you and if someone else from the future will give me a t I will replace s in a and return you a b and the good thing about it is now you can compose them exactly as you compose the processes we saw up to now and when you do this if you squint your eyes a bit you see that we are doing something that is basically equivalent to that cumbersome composition we had before but now is again graphical like you can just compose these Lego bricks together again and this is the art of compositionality anything that really changing is the point of view so you can still deform this thing in another way I'm just rewriting the top diagram as the bottom diagram if you see the interconnectivity of the diagram didn't change and I can shape it as a comb basically and again is the same like you get a in you get an s out then you get a t in and then you get a b out these is really interesting because when you look at this process it really looks like something that wants to be a normal function but it can't because it's waiting for you to do something intuitively if you have an automated way to turn s into t that thing would just be one of those naive building blocks we saw in the beginning and you know in this framework composition will be nested it would be of this sort you are basically composing by substituting a comb in the whole of the bigger comb and again this composition is exactly the same when you follow the the processes and interconnections of this one this one and this one are the same thing we just deformed the way we arrange diagrams now again as I said you can see a comb as an incomplete process that basically is waiting for you to do something to turn a nest into a t and that would be that f that you put there and if you put it there this thing basically closes up and just becomes a normal process but what is really interesting about this is that we found a pattern so we started by modeling record rewriting but now we found a pattern of composition that is this kind of nested composition and indeed there are a lot of things that compose in this way if you abstract from details for a second these two processes are basically representing two different points of view of the same thing that is bidirectional transformations now let me give you an example of how you can use these things an example what is an escrow trade an escrow trade is when I want to give something to someone but I don't trust that someone or that someone doesn't trust me and so what I do is I take my funds instead of giving them directly I lock them up in a bolt and then basically you know my counterparty will ship me some goods and when I receive them I will confirm that I receive them and at that point my funds and forward it and that is exactly a comb looking thing is like I committed my funds I locked them and now I'm waiting for confirmation and as soon as you give me confirmation and you put it in that comb then this looks like a standard transaction from A to B another example and this will be the main point of the second part that my colleague Philip will do is game theory so we can model games in game theory as open processes basically in that case a game will be a process that has again two inputs and two outputs it will take in input an observation so it will observe the word it will spit out an action according to some strategy it will receive a payoff from the outside world and it will return a feedback the feedback is probably the most difficult part to get in this composition method and you have to imagine it one of the ways to imagine it is the portion of your payoff that you have to return to someone else stupid example if you take a debt you place a bet you win you get a payoff but you have to repay the debt and the debt repayment would be the feedback wire in this system of compositional game theory we can recover traditional games as a composition of processes so this for instance is the prisoner dilemma I guess a game most of you are familiar with and normally we see it as a payoff matrix and you know like if player A does this then this is what happens if player B does that blah blah blah in this case prisoner dilemma is the composition of three different processes player one player two and payoff matrix these three things in isolations are games player one and player two are games that do not observe anything because you don't do any observation in the prisoner dilemma they just act they just you know express a choice and they receive a feedback for that choice the payoff matrix game is a game that doesn't act it doesn't have any basic value but it just observes the players move and returns some feedback and again you see that in this setting the player's payoffs are the payoff matrix feedback and the players actions are the payoff matrix observations so yeah the cool thing about that is that now we can quickly prototype games by basically creating networks and interconnecting them with each other one thing we are currently working on and Philip will show a demo of this is for instance a way to lift evm bytecode to open games automatically in doing that you know if you deploy a smart contract we can take your smart contract and put it into this framework and then we can strategically probe it your smart contract would become the payoff matrix in the system and then we can economically probe it with players that can be honest or untrustworthy and see you know which strategies are actually winning strategies or not and so if your contract is economically sound economically stable or not or in within which bounds it operates financially in the way you intended so this is the theory part that is concluded and I will give for the second part everything to Philip and basically yeah in this short tutorial we saw how we can use this compositionality techniques to guide our intuition in designing processes we started with something very simple then we did a bit more involved examples and then we found out that those examples were actually modeling and more general pattern this bidirectional composition and we were able to basically recycle that pattern to instantiate other things like escrow or open games and yeah that's everything for me and I'll just pass it to Philip. Thank you. If you have any questions yeah sorry if you have any questions we can in the meantime that Philips who looks up the computer feel free to ask sure. Define that yeah I mean in here I kind of cheated because I have basically just defined an optic as you know this box obstructing the details indeed mathematically you can prove that I mean the definition of optic is exactly something that embeds that thing mathematically it's a bit complicated to describe but graphically that's exactly what it is an optic is something that has this sort of nested notion of composition basically sure yeah there are various ways to do that Philip is the expert in this and I don't know maybe you won't answer that. Yeah sorry what's your question whether you can also do repeat it yeah yeah you can do that so the game that for piece of short is a one-shot game but you can also think about this as taking that let's say you want to iterate it finitely many times you just stack it on each other the only qualification you have to make if you look at the slide there were basically the wires we're not coming in from the outside you have the game with wires and then you can stack it basically alternative way to do is also you can turn it into a Markov game and basically think about it as approximating it to be run infinitely okay other questions to the first part there is a question to the first part let me do the following I'm trying I'm jumping on my slides ahead to show you this then I will go back sorry could you guys sorry can you switch on the okay let me go to the you have to think about it as two dimensions right so time flows from left to right and if you start from the left there are two things P1 and P2 they are not connected which means they happen in parallel so this is simultaneously happening then afterwards the output and move which is Y1 and Y2 that move is consumed by you which is a payoff function and in that sense you follow sequentially after these two games right you can also think about these two games P1 and P2 being merged into one and then it's just big two games being stacked on top okay so let me go back to the start you can already see what is coming okay so what we want to do in this in this part in the second part by the way hi I'm Philipp thanks you thank you all for coming what we want to do in the second part is basically take a deeper look at compositional game theory as one specific instance of how you can think about compositionality and what compositionality possibly can give you as value to as an approach to thinking about in that specific context of strategic interactions okay compositional game theory what is that actually so it's a at the beginning actually this was a research project which was focused on providing a new formal language for game theoretic reasoning you probably have heard about game theory most many of you probably have already seen it it's a mathematical language to express the reasoning about agents and what we provide is just another language in some sense and this language is as for pizza already introduced based on the categorical framework and this has several consequences one is you give you first of all you get a graphical way of reasoning but most importantly you get a way of compositionally approaching the modeling problems that you face okay now if you just do the diagrams and you know suppose you would be forced of you know using diagrams for very large systems like a staking protocol complicated systems that would be limiting it would not be that much help it might be a cool new theory it might be of interest because of academics but practically maybe not so much relevant what is up what however is the consequence of what also for pizza already said then we there is a very close connection to optics and optics allow more or less these things to be directly implemented enabled us to also develop on the side a software tool which basically takes the language of category theory for modeling games and turns it into a software framework that you can use that supports your modeling process and that's the key thing because if you would be forced to do things on pen and paper well yeah would not be that practical once you have this tooling in the back then you can actually leverage the basically the benefits of compositionality and the purpose of that basically second part is hopefully to convince you that at least this might be interesting and hopefully even more that this might be really useful okay so a large chunk of the talk will also focus on the implementation so what does the implementation actually provide first and foremost it's just a framework in which you can express and represent strategic interactions like the prisoner dilemma but obviously also more complicated stuff many times you're not only interested in representing models but you naturally are interested in you know what kind of behavior may result from these models so you also want to analyze them in various ways in the current engine there are basically three ways to do that one is interactively so you basically run a session and then you can query your model let's say I'm looking at a staking protocol and I have some idea what would constitute an honest strategy of the participants and then I can ask okay if I'm feeding in a strategy is this actually an equilibrium or do specific agents have an incentive to deviate and the way it works is a bit like a proof assistant it will tell you you know your proposition that these strategies make sense either make sense and then it's good or it will they will the compiler or the engine will tell you wait at least one agent basically has an incentive to deviate and here's the incentive use a specific action that this player can take now the interactive part is very useful to explore parts of the model and for the staking stuff we will also see an extended example on this it's quite useful to think about specific vectors of attack and then you can verify does this actually work or you know what do a specific agents actually react to if a strategy of another player changes you can also think about this for Peter alluded to that that there is a system A which is somehow represented as an open game or several open games you make changes in that system these changes propagate in your open games and then in the back you're running tests on what kind of behavior would you expect from this kind of system that you have an incentive mechanism and it works but you make a change to the overall protocol a how does that actually is then this is translated into the open games framework and in the back you're running tests on the behavior of the agents and then maybe things go through or you get a warning something is not working anymore as before and lastly theoretically as well as from a practical implementation perspective there's a very close connection to machine learning framework specifically reinforcement learning I will say a bit more at the end if I have time but the idea basically is that you can either leverage reinforcement learning techniques and machine learning techniques more generally for solving and analyzing games solving of course has limitations because it's very complex but for some specific games it's feasible and on the other hand you can also turn it around you can also make learners basically part of the game so that you have an interactive interaction of learning agents basically which is also quite useful because you basically can think about this as you know institutional players updating or actually learners themselves as part of the model for instance in pricing settings okay what's the key innovation well compositionality obviously that's a key point but what does it actually mean here if you think about the prisoner dilemma what is already showed is that you can think about the prisoner dilemma at least from what you have seen so far as either one monolithic building block or at the minimum you're splitting it up in three components right now for a prisoner dilemma that's not that relevant but the more complex your scenarios become the more helpful it actually is to say look I'm taking that part I'm zooming in I'm modeling it zoom out take another part model that zoom out and so on and so on and later on if you do it right you have basically systematic ways of composing these things together into a bigger model now this doesn't end at that level you can also for programming purposes or because of convenience you can further modernize your code let's say there is a specific thing a specific way you want to approach it you can split this up implemented in different ways and the key thing about all of this basically so far is that all what you're doing will be guaranteed to make game theoretic sense if you follow the syntactic descriptions or restrictions of the engine that means you start out modeling if you use our language you end up you can decompose things each of these components will make sense from a game theoretic perspective and the composting will also make game theoretic sense that's compositionality and action why is this useful well you get an overall view on your situation that you want to model and it is sound and you can ask questions like okay what's the equilibrium of that or if we repeat it is there a deviation strategy if you think about more like a Markov strategy for instance are there ways of deviating that are profitable for specific players another perspective basically is that this turns the modeling exercise into a programming exercise so the idea of zooming in and zooming out sorry and modeling parts in isolation is more or less like divide and conquer a typical pattern that you would apply or in many programming problems okay and the key thing again is you can modelize your code further we will see this later on we will have regular household functions that we just lived into that and you can change these components but as long as you're staying inside of that system you are guaranteed that these things make are kind of well defined now a warning the fact that this is game theoretic well well defined does of course not mean that your model makes sense you can model complete garbage we can't help you with that if you really intend to do that but what you can guarantee to you is or what this kind of helps you is at least in the process of modeling you have a scaffold that you can use alright so how is this useful the main thing basically is I alluded to that if you can apply divide and conquer you can easily deal with complex scenarios it overall also it speeds up the process of modeling in several ways first you know division of labor so in principle the larger the systems you can actually very easily collaborate with people secondly if you want to change a component you can easily do that as long as the rest stays intact and lastly because everything is expressed as code there is obvious reuse for components and you know we have had several projects in the past and we can see that there are some patterns that just emerge that you can use over and over again which is useful because it speeds up down the road when you want to model something okay and of course when I mentioned this already before you can also think about it as just being part of a larger stack where it's fulfilling a certain service like testing properties again on the safeness of the system from an economic perspective okay this is kind of the introduction very roughly what this engine is doing why it's possibly useful why it's maybe interesting what I want to do for the rest of this workshop and for basically the second part I will give you an intuition about how to model with this tool how to represent games and again the focus will be on showing that compositionality is actually useful or hopefully useful secondly I will also give you an intuition of you know how does an analysis actually work what does it look like I will be shorter on that second part the reason is in order to make sense of the analysis you obviously have to have a deep understanding of the model this is given a type constraint it's not really feasible but I still will give you an intuition of how does it actually work how does this look like okay and a leading example that we will converge to is basically a staking protocol it's a simplified model that illustrates these two components of compositionality and also the kind of analysis you want to run in this system good I start with not code but directly coming back to what repeats are actually namely introducing a bit theory this will be partly repetition but it doesn't hurt it will be mostly about diagrams so not much mathematical content the reason I do this is the theoretical approach is more or less directly the way that the implementation works model of some kind of difficulties in the back obviously if you understand how the modeling on the theoretical side works you basically have a very good idea of how the syntax actually works and operates and that means you also basically know how to use that that engine basically okay so you have seen this this is a bi-directional information transformer transformer from both sides so X is transformed into Y and then there's something coming from R to S both directions again convention is if you want to think about this is that time is on the left so on the side of X and S and the future is basically the passes on the X side and the future is on the Y side okay now in some sense in the essence of conversational game theory is that what we showed is any kind of game that you want to model has this shape and can be put into this shape whether it's just a single player making a decision which is kind of a non-typical game or a very large complex system many players moving on interacting everything can be modeled in that shape whether it's very large or very small now why is this good or why is this useful well it's useful because you can start out with small components like one player maybe just also computation something very trivial and you can block these things together and slowly from the bottom up like Lego blocks you can build up a system that is quite complex and of course because you're programming you can also kind of box things and say well this is a pattern maybe two players interacting in a certain way this is quite useful you know I'm giving that a name and I'm really reusing that component over again okay so everything is of that shape it's a bit like it's like a closure property in some sense you start out with a number you end up with a number it's the same year you start out with one game compose another game you end up with another game and this is in some sense what I referred to before as this guarantees you that you stay in a formally well defined framework okay let me come back a bit to the concrete implementation of this specific box and for the next few minutes think about this box as just one player doing something now one way to think about this is essentially the player is just doing some kind of information transformation right so there is something coming from the past a move information whatever acts the player observes this and internally something happens he's outputting a move why okay now the question of course is what kind of move will the player make this depends on what kind of moves he has available but it also of course if it is a game theoretic agent and assume for now it's a rational agent who wants to maximize something he needs to think about what's my effect of choosing why on my utility and you see that the wire is an open wire so it doesn't really specify exactly how it is interacting yet within my with the environment but what we can say is the player is expecting an hour back from the environment and this openness between my action why and the payoff that are or whatever actually are is in fact what I receive from the environment that openness makes it possible to take it like a building block put it in specific situations and then sometimes I might be able to close the loop in a certain way the most trivial way of closing it would be I have one player and I'm just bending the Y back into R and then basically my why my action that I take will be directly the thing that I observe and I affect I have full control basically those interesting scenarios from a game theoretic perspective are obviously not like that but my why will not solely determine what my payoff actually is like in a prisoner dilemma there's another agent doing something and this will also affect my payoff and of course this is the idea that at some point we will give a concrete environment which determines how this Y actually is bent back into a specific payoff whatever result you actually care about as an agent okay so that's the basic structure now as I said before we are building up from the bottom what we want is we want to compose larger games by composing simpler games and what we need for this are essentially two kind of things we want some building blocks think of it again like Lego you have one specific thing and from that if you have it and you have more of them you can just build up a wall for instance so we need the building blocks the atomic units if you like and then we need operations how to compose stuff on the buildings on the atomic building blocks we have essentially two which is a decision a single player making a decision and a computation computation means just some input is observed some output is basically the result these computations can have side effects so it could be actually a deterministic input is turned into a probability distribution or a probability distribution as an input is turned into another probability distribution good what are the composition operations for those of you who already followed Fabrizio you will already guess it it's parallel and sequential composition parallel in the game through the sense is maybe more easier interpreted as simultaneous and what it looks like essentially is again repeating a bit of what we have seen you have two games G1 and G2 if they are in parallel you can compose them and then again we'll have this basic shape of input X X2 in that case turned into a certain output and it's the same time expecting a certain result and sending some information back into the past okay sequential composition you have G first H following you can stack them on each other so that they look in the following way now what is important so far I haven't said anything about what these labels X, Y and actually correspond to you can think about them as shapes and only games that actually have the right shape can be stacked on each other and this is important because if I say give me two games and I can compose them you might wonder that sounds weird how can this be possible in generality I can easily come up with two games that are not so easy or maybe not at all composable the restriction that you have is that these shapes only then can you stack games together for bits are already set from a categorical perspective and then of course also from a programming perspective these labels will be types so only if the types match up can you actually stack games together this is quite useful and it's actually an important restriction because if let's say G is outputting a boolean and H is expecting a numerical value, a numerical type you can't match them up basically but what is even more important if you try to do that the engine in that case the Haskell compiler will loudly complain that this is not feasible you can't do that what is more because you can obviously design your own types you have also degrees of freedom of being very specific about what kind of input type is actually expected so it's basically also part of the modeling effort that you have control over how easy is it actually to stack these things okay and full circle back to the prisoner dilemma again I already alluded to it just very briefly what this is actually representing two compositions first parallel or simultaneous between P1 and P2 and then sequential the U and again if you go back to the parallel composition you can basically think I'm first composing the two players in parallel into again this shape and then I'm composing that one sequentially with the utility function or the payoff function okay questions so far yep can you explain why the utility function is applied sequentially yes in a sense of the utility function essentially is just a computation right so it's waiting there for you and it's waiting for two actions one by player one and one by player two so it has to wait until these actions realize in that sense it's sequential in the implementation that I that I show you will see this directly as variable output of P1 being fed into the U okay other questions okay implementation first a bit of an overview so what is actually what does the implementation actually look like it's a domain specific language embedded in Haskell you might wonder why Haskell one of the reasons is that and Fabrizio already said this as well as well the optics and lenses are something that exist and you can build the implementation basically on pre-existing structures in Haskell which is nice because your theory has a direct correspondence to the elements that you use for the implementation in other words it makes it also easier to control that your implementation actually is correct okay another thing which is quite useful the typing system of Haskell is actually can be well sometimes your enemy but sometimes also your friend if you have larger components larger operations and you wonder what inputs if you want to query games do I actually have to supply the type system is quite useful because it infers the types and it can tell you your strategy that you have to supply has the following type right it has is a tuple of double or maybe something much more complicated this sounds at the beginning kind of you know why you need yet why would you need that but the more complex your scenarios are the more useful these properties and this functionality actually is okay this is under active development it's under the active development from two sides from the programming perspective of things we you know we feel like features that we want and we want to implement but also the theory is continuously developed this is something I will come back to at the end if I have time okay we are using it for a couple of things staking protocols an example a simple example you will see today token design and there are also applications outside of crypto good the first thing we want to focus on how does the engine actually work in a sense of how do we represent games how does this work all right so on the left you can see again the game with the inputs and outputs on the right hand right hand side you basically see the syntactic expression which is basically this square bracket open game and then what follows until the last square bracket that internally is basically the DSL and tallying here is a game coming with a certain shape okay there is what is called internals of G between the dashed lines I will say something about this in a minute first what you should see is there are four fields inputs feedback output returns and they exactly correspond to the wires so you can see this as basically a way of expressing a two-dimensional element kind of language into the language or the programming syntax in within Haskell so the inputs are just the outside system another way to think about this box essentially is each open game is almost like an interface right you have something internally happen but to the outside world is somehow it is connected or maybe not connected through its interfaces that it offers what happens internally internally is where the place of where the information is generated so the insides of these dashed lines there are what we call line blocks these are five lines basically they roughly correspond again or mirror the outside wires so inputs feedback output returns and then there is an additional field which is the operation field that is essentially where information is created now the first thing to observe is in a simplest game if I am just talking about one single player making a decision the input X could be exactly linked to the outside wire X that I showed you before and is the wire going out or actually coming in similarly the output Y is we will be the result of the information that is created and will be directly pushed outside of the box however this is not necessarily the case in the sense of there could be more line blocks there could be more complicated things and some of these inputs and output fields could be just totally consumed inside of that game without any exposure to the outside world the operation can be two things like here this is the dependent decision just means this is the decision operation so one player makes a decision or alternatively a computation these two building blocks you don't need more if you have that you can basically build the most complicated model you want ok here is the prisoner dilemma again the diagram from before first you can see if you look at the left hand side the outside interfaces here are empty this tells you two things first you don't always need to apply information sometimes the games are not connected to the outside world or only partly connected and internally what you can see is there are three line blocks the first and the second basically are player 1 and player 2 again for both of them they don't observe anything from the past there is no input the output something which is the decision player 1 and decision player 2 something from the environment back this is the pay of player 1 which are only defined at the third line block which is the pay of PD this is the utility function and here coming back to connecting to your question before this function is expecting basically an input from above which tells you this is a sequential a sequential composition keep in mind the diagrammatic language is two-dimensional Haskell is not ok now the last element the pay of PD is also outputting the pay ofs and these pay ofs are then connected back to the players and you can see already certain elements of Haskell also help because the order of where these things are actually don't matter and it helps in the evaluation later ok question so far is the syntax roughly clear at least the idea so yeah you have a question I wanted to ask thank you I wanted to ask about the inputs and feedback before and after the internal definitions are those the inputs going into P1 you mean outside of sorry on this slide yes so the first inputs and feedback ones that have a blank yes ok I should have been precise thanks for the point so what is actually the inputs would correspond to an ingoing wire into the overall game I could think about the overall game as a box itself right so this is just one box with possible ingoing and outgoing wires what it essentially represents is an empty is not an empty box but a box which is not connected at all to the outside world right I'm cutting just away four of these wires and wires is relevant actually so the thing about a prison at an emmer a one shot game it has no past and it has also no future by definition there is no need to send information back or send information into the future and topologically I can represent these features in the sense that there are wires or they are not wires it's also useful in the sense that if you model more complex games you can see that only when there is a connection through a wire there is actually an effect happening so sometimes these diagrams can be extremely helpful in understanding what are actually the dependencies thank you other questions so in the last part I want to look at a staking model this is a simple model still in the sense that I can mostly explain all the components that are needed in the scope of the workshop the motivation comes actually I would actually have said that part of the engine were kind of funded by the theorem foundation and we were working with the robust incentive group and it was one of the examples they prompted us to work on and that's basically what we did so this is a simplified version of that work I will focus on compositionality, you can guess it already specifically now what I want to show is how I'm basically not composing things but I first will actually decompose stuff I will look at the overall problem and I will put it in as small parts and bits as possible I want to also illustrate what I can do as a zooming in operation I said before all of the components are making game theoretic sense which means if I'm modeling something complicated I can, when I want to obviously look at the overall complex thing and analyze this but sometimes I might not care about the overall thing but I might just care let's say the validators in the staking protocol what are they actually doing for a specific input what I can do then is if I have the model as a specific component I can just zoom in to analyze this specific thing without regard of the rest it's a bit like unit testing of specific units if you like which can be extremely useful given time there are obviously more details that I cannot explain all the details behind it but this is explicitly based on a blog post that we wrote which gives much more context also on the relation to where the idea for the model comes from and also all of the components are explained in detail so what's the basic setup here we have essentially several periods possibly in each period there is one proposer and there are two validators what are they doing the proposer basically observes the chain I will say in a minute or give you a picture of how this actually looks like and the proposer basically observes the chain and then decides I want to extend the chain and basically says there are several blocks and then again it's simplified and what are the validators doing the validators basically observe the delta between what was the chain before and what was basically the result after the proposer moved and then they have to make a decision on a voting decision on what do they think is the legitimate head of that chain and legitimate obviously in the sense if they are trying to be honest and are not malicious we will be using Haskell obviously in Haskell this will be what is called an algebraic graph it's just a simple graph here each block has two information namely an ID and then the votes in that specific example here this would be kind of the ideal world we started with block one built on that block two and so on have a linear chain the votes are in everything looks fine if you take that as a specific input for one period let's say this is before coming what will be the action of the proposer the proposer will basically say yeah I want to build on that chain I'm choosing in that case I'm choosing ID three which is the legitimate head according to the protocol that we are interested in at that moment he makes the decision that block gets appended but there are no votes yet and then the validators come in they observe the ID which was proposed and then they can do everything is very nice this is the really nice world here okay however sometimes things are not so easy specifically if everything would be deterministic then obviously all the problems would go away but you have networks issue in reality which means these taking protocols are hard you have to think about certain problems one of the problems could be that what if there is a time lag between the proposer and the attester and what happens if here there was a proposer in period 4 and he's actually malicious he's just letting time pass by at some point proposer from the next period observes the chain okay the other guy hasn't done anything I'm building on that chain and legitimately he's honest builds on ID three and that moment before the validators come in said the first the proposer from period 4 actually sneaks in and places in all his own block on that chain so he's forking basically and now the question is what happens this is one of the motivating examples okay do you have questions to the basic setup more details follow okay if not let me jump to um that's not really looking nice can you read this should I increase the font is it okay okay left hand side is basically the model right hand side will be just an interactive session that I will be using let me start with something first in order to implement the model you need a lot of background information right I need to actually think about what's the data type of the chain if there is a new block being proposed how do I actually edit this is for instance this function here at chain it's just observing a chain it's observing an ID which was proposed and it's you know creating a new chain so I need a lot of background stuff in order to make this model work which is just basically you know Haskell in that sense Haskell functions and computations another one would be for instance determine head clearly in order for the protocol to work which has a certain goal I need to be able to at each point say what are the head or the heads if they are non-determinant and this is basically the second function what it's doing and there is a lot of other stuff that I'm not showing you that comes in so you need for that in order to kind of use this you need first this structure in order to basically this is the computational background to which I'm working now you might wonder okay for you know wouldn't it be nice if this would be coming from the outside world and indeed for some problems you just need to create it but in other cases and this is something we will be working with in the future or towards is can part of that basic infrastructure that we are interfacing with in the end and that is actually not that interesting from your modeling perspective it's just something you want to take as given can you somehow import it from the outside world or can you connect this to the outside world okay for this purpose here I'm just recreating it what it actually does is not so important just think about it for now what the behavior is with a chain and so on and so on some functionality I will explain on the fly good these are all functions the first thing we want to do we want to create basic building blocks that we will be relying on I said before we will be making it here really really kind of fine grained in the sense of let's make add to chain actually an open game put it into a computational framework so that we have a building block that we can move around if we want to similarly let's do that for Determined Hat maybe we need it at different points and then we kind of have this building block available as an open game also note essentially for the whole system here the protocol logic is exclusively in Determined Hat this is this function that you can see here if you change that all the rest stays intact that's another way of if you try to approach the problem in that way you will save a lot of redoing if you want to make changes to the protocol okay let me jump here okay so I showed you the function before let me actually put it next to each other so add to add block basically is doing nothing else it's just a computation it observes the chain old and observes an ID and then it puts that into the inputs field inside basically this is the forward function keyword remember we had the decision and basically computation this is one instance of the computation and then it does just the add chain to wait which is similar to what we have in the add to chain why the wait I can explain in a minute but in principle it's the same idea you just take a component and lift it into an open game it's just a computation similarly determine head of the chain here as you can see this input here is basically just a function from the right hand side I'm lifting it into an open game just a building block good these are very boring building blocks so let's move on what do I need I have proposer and I have validators so what makes probably sense is to think about how does the validator actually look like okay let's model the validator if you think about what the validator is doing as I said before the action he does is he observes the new chain he observes the delta which means he also has an access to the old chain that's the input here that's also the input to the line element here and then there is a decision and what you can see here in that expression is just basically that's telling internally the dependent decision operator what is the action space where does it actually can choose from here this is basically just not the ideas of the blocks from one until the vertex count basically how many vertex are there and then this is basically the choice that the validator can do okay so we have basically a bit of computational background adds a block we have to determine head of chain we have the validator now we have the proposer okay what is the proposer doing well the proposer observes the chain also internally he makes a decision what decision does he do well he can choose basically on which block to build that is the outset this is the decision proposer which is coming out here and then you can see this is the first game in that context where we have another line block there's some kind of additional functionality this is just basically producing the new chain this is taking two graphs as I said this is a specific library from Haskell which is algebraic you can just plug things together and then you can do the new chain and the output so the wiring of that game is basically chain old and chain new this is my interface of what the proposer is doing okay now the thing I cheated you a bit on two places maybe you already spotted it if you look at for the validator as well as the proposer if you look at the return type here a return field which is kind of weird right because I said before isn't that where actually the strategic context come from the environment telling me what to do blah blah blah and now I was just saying it's zero doesn't look really strategic now this is an instance and I will come back to this this is an instance of where we actually had exactly what I just blah blah namely we had the inputs coming from the outside world and blocked them through but then realized that there is actually a very neat useful pattern here that we can abstract out the payoffs in a different way this is in some sense a bit of Haskell background that made it possible to kind of split this up even further that is what I meant initially when I said when you start modeling in this chain you can of course sometimes realize just programming patterns classically abstract them out and replace them with something else why is this actually happening in a sense keep in mind for the protocol to work in period T the decisions of proposer as well as validators are not rewarded in the future that means their reward actually is conditioning on what is coming from the future and this is a way and I will show you in a minute how we actually can deal with this and the same is true for the validator as well as the proposer ok so here's an example of what you can see basically how this is done this is what is called update payoff validator this is an auxiliary thing the bool is basically was the validation correct according to the protocol that is then determining the payoff payoff can also be negative so basically the protocol determines what this validator did actually in T in T plus 1 doesn't actually look good so we will punish could be a negative value ok that value is feed forward and then there is this add payoffs construction this is just another open game and what internally is happening is actually this is associating the payoff to the player which is parameterized by name so you can put this component in different places and it will automatically add the payoff at that point to your player do you have to do it in that form? no, as I said before you could also kind of make it more with the wires and so on but this is a pattern which makes it extremely lightweight of recomposing the payoffs and again this is useful for the following reason if you think about and for here I'm assuming the payoffs are passed in one period advanced the proposer do something the validator do something and then in the next period it gets evaluated what they actually do of course I could have a protocol which actually takes more episodes what do I do then? I can of course kind of take the wires put them through which is still ok but I can also just use it and say well the information flows in direction and I can compose this value add payoffs with the same name with the same identifier again at that point and I'm done with the identifier but it's just something which emerged out of working on this and there are other examples like this ok these are the components that we need now we want to take the next step first let me also we have not only one validator but we have several what we do here we are grouping them together so we say well there is a chain new chain old input and then there is some kind of information this is just information about pass behavior from the other validators from the period before and then the thing is what you should observe is the following here and here validator this is the construct which is on the right hand side so we take that and plug in the open game here and this is basically the second step of nesting we already have one for the proposer but for the validator basically we model it as an open game and then we plug it into the group and now you can also see the structure basically of that component validators group decision is made that you can also extend the number of players if you want you just basically add one line here add functionality but the overall interfacing of that group of decision making process is the same whether it's 100 or just 2 and there are also ways I should say this you don't always have to make this explicit if they are symmetric in some sense there is also convenience patterns that just can say here are 10 players of the same type put them there good so this is the validators group decision we also need to make the payment for the validators again it's not only one validator but two and again you could think about this as being extended to more players the thing to keep in mind is and I repeat myself but it's important this validation step is in time T for the behavior of T minus one yes you have a question okay maybe you ask a question again and everyone yeah it was asking I'd like to know what's operation the operation field basically the operation field is from one perspective basically where the strategic information is created if it's a function it will be just saying let me give you the example here I'm filling the operation with basically two keywords namely either forward function or dependent decision what is the forward function doing a normal haskell function into an open game which means in the simplest case it's just a deterministic function that determined hat takes a chain and outputs a hat and then I'm interfacing it with the outside world if you're talking about a decision it's different look at the validator this is the key word dependent decision the validator in this case the decision is the following the player observes this chain U, chain old that's his observation, his information let's pick an element this element in that case is an index to which of the block elements do I believe to be the hat or I'm choosing to be the hat yeah okay wouldn't there be an operation between returns and feedback so you say again so this is doing from left to right movement correct what about the other direction okay that's a good point so first it takes one step back if you think about the prisoner dilemma there was also the case where the agents did not send information back into the past yeah okay so that explains and the reasoning is simply here I don't need to send the information from these players back into the past and the reason I don't need to do that is there's basically the protocol is moving forward and I don't need to send this information back it's like I'm creating a state and the state will summarize what is going on why I'm doing this in this form is the following reason I will end up with one episode that episode will be basically a basic game for a Markov game and then I can stack these again on it on each other and repeat them if I want to now you're right if you wanted let's say you just explicitly wanted to model two episodes you could say parts of these elements for instance what these guys expect here what the return is is actually coming from this returns field over here and I said before you can do that and the reason I'm not doing it is here is exactly for if I want to stack more episodes with payoffs still being created for players in let's say T-4 I can easier do that okay maybe it will become clearer when we come to the rest if not feel free to ask again other questions could you tell me the time I have no idea 25, okay good okay well it is payment again this looks like a bit more convenient stuff but this is the question we should ask if you model it yourself is how can you model it in a way that is actually really a building block I said before one way of doing it is that the interfaces are relatively flexible so I'm just leading the fee which is an outside parameter and then internally basically I just need the payoffs I need to chain new and the head ID which was chosen and with that basically I have the full picture and the protocol can evaluate was the behavior actually correct okay and you can see this is actually happening in a function that I didn't show you this is a tested correct the tested correct is basically just telling according to the logic of the of the protocol the information I got yes made sense or no and it's outputting a bool it's just saying yes or no and it's doing that for player one and it's doing it for player two and these then corrected attested are basically input into this function pay off validator here on the right which you can also see here it's just taking was the validator correct or not and then it's basically updating good okay also what you should see and this is kind of coming bit back to this discussion on why is there no information being sent back this is also there's also no information sent in the future right if I would be doing this again without my way of composing this one player which is magically updates I would have to explicitly feedback that information so here you have essentially boolean values that are that the outputs which is the correct attested one and two but then in a different block you had an input and output that was actually cold bull so I'm a little confused whether that's this is supposed to be like a label or type okay this is basically the question of the scope of the of the environment basically so the reason I call this bull here is I'm just telling now basically me for the reader I know this is a bull and I basically know what is happening why am I doing this here differently I'm doing the correct attested because I'm giving it information that I can easy I pass it right if I would be just saying bull in that specific context I might know what it is but I don't know where the bull is coming from right so it's like you might disagree with my basically with my nomenclatura or with the way I label things but for me internally it was just like I understand what it means and that's the reason basically the thing to keep in mind in a categorical framework because you have these wires going in basically bound variables come in the outgoing wires are basically binding new variables to the output so in case of the correct attested I'm binding a value that is the outcome of that operation to that specific correct attested which means if I'm reusing it it's bounded okay other questions alright let's continue so we have the validators payment and now we have everything assembled for a one period game one episode game okay this is this beast here just barely makes it on not completely what it basically tells you is this is one episode I'm now putting everything together there are certain parameterizations ignore them for now they're just details of you know how do I call the players what is the reward and what is the fee and so on you should really think about it again as an as a diagram with in going outgoing wires so the in going wires are basically chain old head of chain from the period minus two validators map this is just basically summarizing the information of what the validators have done before and in principle you should think about is I keep enough information so that the protocol works in a simple case here just one episode if there would be more episodes this would be it's just a record type basically it would contain more records okay what we then have basically is the proposal moves first he observes the chain he outputs a new chain keep in mind this is this again so he's observing the chain and then internally is also at the same time creating the new chain this is a computation taking place here okay proposal moves new chain is created then the validators move as a group they observe the new chain they observe the old chain there's also access to the old information validators match this hash map old and then they make a decision they create new this basically new map containing the updated information how did all of these validators actually behave and they also have the chain updated because when they cast their votes remember the shape of the of the blocks are basically an ID and a voting value alright the thing to remember and I'm repeating myself I know but it's important to understand what is happening that the payments basically that happen are happening not for the decisions that are made by the players in that episode but from the episode before or if I would be looking at a more longer horizon from the episodes before good after this this is the main things the decisions are made by the proposal by the validators now I'm basically doing bookkeeping I'm determining the head of the chain I do the validators payment this is from the past I also check I didn't explain this but this is basically also bookkeeping I just look at what was the old proposal actually doing did he actually do something and then I'm getting that as an input to the proposal payment again for the period before now the complicating thing here is that I'm targeting a model which itself has a structure that if you just look at the output chain new updated head of chain and so on validators hash map and you look above you can see there's a pattern basically the input types here chain old head of you can't see that but I'm telling you the input type chain old head of chain and that here are exactly the output types which means now I can take the one episode and just say okay maybe I want to run it for three episodes I'm taking the same element and I'm just connecting them or I'm not doing that here if I want to run this as a Markov game and I want to approximate it like I'm running this for a long time I could just basically use a specific operator we developed that you can then I'm repeating it so you're starting initializing the game you create a one-stage output that is fed back into the next period and so you go on okay I'm not doing that here I want to jump for the last part basically a bit and looking into how do you actually analyze these games I mentioned before in the slide what I want to do is I want to illustrate a bit of what is the zooming actually what is the zooming how does the zooming work I'm focusing on the one episode I'm actually ignoring any kind of repetition clearly if you care about the overall protocol at some point you have to think about the dynamics and also longer time periods but for some questions it might be relevant to see is it actually working locally to give you an example suppose you're interested in honest behavior by a proposer as well as validator and I'm giving you I'm initially initializing this with specific inputs and I'm testing in that one period and I'm trying to understand if you work in that way and if not if you find out basically just by zooming in on that context it's not well you just can put everything else aside you don't have to think about the dynamics that's enough similarly if you care about let's say vectors of attacks very often it's enough to focus on specific parts in order to evaluate whether the attack is actually working or not question? no yes I said in the context of modeling the domain of a game and a software team working with a program like this if they have to liaison with the product team which will have an understanding of the UX wouldn't it be easier for them if they want to model attack vectors to just model what the agents could do and then use a genetic algorithm for example might well be depends on the context the key thing is here you have basically the best of both worlds you can just look at the one component but if that is not the only query you want to do but you also want to look at the more complicated stuff you have it as well in principle what you could do is actually you can take this component interface it to the outside world run some learning algorithm on top and that's it and it will be exactly the same thing but it will be part of the overall consistent framework and that's an important thing if you care about the design for instance you want to make sure that everything is somehow consistent obviously and then it's much easier to say you want to make sure that everything is consistent with the element which is consistent with the rest and just interface it to the outside world and then simulate it clearly I mean this is also Haskell I'm not sure how many people will be using it in that form that's another question I think lurking in the back so this is at the moment actually to work with that you don't need that much Haskell because you need to understand the syntax of the engine and most of what I showed you is inside clearly you need some kind of knowledge of Haskell to work with the outside world and you have a domain-specific language and that's all you need to know and you have some operators on top then parts of the pain hopefully go away okay other questions alright if not slide one shall we start again maybe afterwards okay let's jump a bit into the analysis okay here's a bit more Haskell pain for you and even more than average namely we're using something which is kind of what is called arrows if you don't know what it is for now you should think about this as I'm defining a strategy for a proposer as well as for the validator what it is basically doing is the following it's creating a function and the function tells me I'm observing a chain what I'm going to do is I'm basically sending an ID remember the proposer observes the chain and decides on which element to build what the rest is basically saying is this is an honest strategy it does the following determine hat, this is a functionality from before so I'm looking into the chain I'm looking at what is the head of the chain according to the protocol if it is, play that game play that strategy if not, if there are multiple candidates and the validator does exactly the same it's basically a super honest as well he's just looking at what's the head if the head is a single value, play that if multiple value is randomized among them good and then basically we kind of encapsulate everything it is reminder this is basically referring to the one episode game I'm plugging in some variables or some parameters which you can ignore for now what is the thing that I'm doing let me actually do it differently so I'm analyzing this scenario and then this is, I should have said this is the interactive way, this is the right hand side this is an interactive session with the high school compiler I'm querying that thing and what I'm getting out basically is a simplistic information namely the output just tells me everything is fine you don't have to worry go home or go to the pub everything is working now, this is a specific thing what it actually tells you the protocol is inspired by one of the biggest by a theorem basically you can see that this specific assumption is working no agent has an incentive to deviate okay, nice and clean so far but now we want to do the following now we want to come back to this picture here I said before that let's suppose in the past period there's a guy who's actually not so nice and he's deciding not to propose he's waiting at that moment, at some point after some time threshold the next proposer, which is the lower one here, basically observes the chain steps in, he wants to be nice he's honest, proposes a new head and at that moment before the attestors can actually be active the old proposer steps in and just basically proposes his own head of the chain okay, there are various ways in doing this I could just model explicitly the attack game and it is actually married to do that but here's an alternative way you can do it and this is I'm referring to the zooming in that I want to illustrate I've created another version here which is doing this one episode attack which is doing a simple trick, namely I'm introducing an additional variable because I'm just focused on this one period I can do that, it's easy which is the chain manipulated all the rest is the same the proposer observes the old chain so he's basically still operating under the information from the past and then what happens is this line block is added I'm merging the two proposed heads into one chain so then I have really fork and then what is happening is that the validators are observing the forked version so they have to deal with the problem basically now, is this the only way to do it? No, you have multiple ways of doing it but this is part of what the modeler has to decide how it can just be done in an easy and accessible way another way to do this on one branch we actually do this is explicitly keeping track of time and basically look at a timing game so that time passes and then the proposer from the first period can until a certain point act the problem is that until a certain threshold all the other players don't know whether the other guy moved or just they haven't received a signal yet but this is much more evolved here I'm just cutting into this thing that I care about, namely what do the validators actually do okay, let's jump to this attack strategy proposer is the same then we have what I call the strategy validator random it's also the same from before I add two new strategies for validators one is strategy validator 4 and validator 5 this is something very simple, namely in case of a tie when there are multiple things I'm just taking here by hand I'm just taking the fourth element and for that specific example I'm just specializing it for that specific thing because it's enough but you could easily extend it to a more general version in other words when there are multiple candidates I'm just deterministically choosing one of the elements and I'm doing the same for 5 but just on the other element now I have several scenarios I have scenario 4 and 5 which is just the same proposer strategy as before, honest in the manipulated chain and then the validators are just deterministically voting for ID 4 in case of a tie or alternatively 5 and lastly the random is basically I'm just taking the element so the honest behavior from before namely if there is a tie I'm just randomizing which obviously is also debatable whether this is a good idea but for illustration purposes that's enough let me run through 4 you can see this is nice, this is also nice this is an equilibrium and 5 as well ok so far this looks like pretty useless because everything is in equilibrium but in fact what it tells you is that subtly we have 2 equilibria at the same time and both are kind of either we go with the honest proposer namely the one who proposed the 4 or we actually go with the 5 which tells you this is not in the interest of the protocol this one of them should not be in equilibrium and you see even more if I'm sticking to the actual behavior of introducing the possibility of random basically just honestly saying I don't know and I'm randomizing you can get different information and this is the alternative namely the system recognizes one of the agents has a deviation the formatting is horrible but both basically focus on the first part the player with the name A21 has a deviating property the optimal payoff is 2 current payoff is 1 what's the optimal action he should choose is move 1 why is this the case you can easily imagine because basically these players try to coordinate and if they are diverging the protocol will punish them so they actually are better off voting for both coordinating on the wrong or in the manipulated head of the chain instead of sticking to their honest strategy so at that moment you see things fall apart with that very relatively simple model and again this kind of it's a simple illustration here but that kind of structure was actually a motivation from a realistic attack good let me close with one more thing and this is then more or less the end with kind of some remarks this is the interactive version as I said before you can also think about this as being part of the system so you can basically also run the testing in parallel or as an alternative so if you do this basically what will happen is you have some kind of specification test this includes the equilibria but it can also be the parts is the sticking protocol working in the right way and then Haskell is actually quite nice on that end because it can create a lot of very well structured arbitrary examples that you care about and then you will see at the end hopefully something green like this which generated in that case I think 100 different starting points for the chain evaluated them and you get some result is basically you can extend this in all kinds of versions it can be either on the behavioral level really thinking about the equilibrium that would be the first test or if you go down really just the components questions before I conclude let me conclude on two levels first a bit more concretely what is one of the next steps for this engine and then circling back to where we actually started so this is connected to the rest of category theory or maybe more precisely applied category theory so one of the things and some of actually former verification people are here we are one project that we have is I mentioned is we want to have more pipeline from as they starting from EBM code into actual open games representation a lot of work has already been done that we can dock on and one project is basically to kind of extend this towards the open games framework so that if you can start with some smart contracts you basically get an open games representation and then you can start querying them either automatically or with your maybe you have some ideas of what you want to query in a manual way or you have some more bigger analysis tools on top the analytics we have so far we are extending them permanently we are also going into different applications and think about what specific analytics are relevant there it's an outside of staking and I should mention this before which is actually an important thing the engine itself the version that you see here is basically built on theory version outdated time minus three or so there have been three more iterations and one of the tasks in the next weeks and month will be basically an update of the engine the theory itself is also continuously developed lastly, compositionality that was the starting point you have seen one instance of why compositionality might be useful in the context of open games what is interesting about this specific example is that when we started out there is this basic question that Fabrizio raised in the initial beginning of his presentation namely how do systems compose in the game theory setting we have a relatively clear answer and what was interesting was in the beginning the implementation and the way we did it categorically is not at all doesn't resemble at all the way it looks right now because at the beginning we had a very different way what we realized is the connection to lenses in the categorical framework what we also realized was actually realizing that the existing deterministic lenses are not enough and this is quite obvious because games need randomness you need to deal with non deterministic moves that actually led also to innovations on the side of the optics implementation and that itself Fabrizio alluded to that is itself now kind of a an area which is almost exploding in all kinds of directions and making connections and extending this framework this is one of the things which is quite nice actually about all of this work that it's tightly it's tying back into other fields within the categorical framework and examples of that are control theory, reinforcement learning, active inference, others to be developed and the abstraction here really enables you to see that these patterns are or that these different instances are actually related to common patterns and lastly what is more you can also make cross combinations one of the interesting ones is actually that you can see that in the games and learning which is not new itself but if you see it in that form and you have this new pattern it's quite insightful and quite useful actually to see it in that form good thank you very much questions? yeah or to me or to Fabrizio maybe you want to so I'm wondering if we can talk about like a real world attack example and how that would come into such a system and in particular I guess on my mind is the mango attack from a couple days ago where it was essentially an oracle exploit and the it seems to me like an oracle would be inherently outside of a system that you're modeling this way or is that is that an incorrect assumption sorry let me go back here just if you think about if you think about this X doesn't have to come from the world it's from the game itself right it can be something from the outside perspective so I can interface this with something which is drawn from an outside could be from a database or whatever it actually is where it's coming from it could be continuously updated I'm running that basically on a permanent basis so this is clearly possible you can also parameterize games I'm not sure you maybe remember this part go there if you look something like this one episode editor attack there are a couple of parameters which are actually exogenous they are not part of the internal structure I can make them anogenous querying them but I can also just say they're coming from the outside and I'm fixing them like the names of the players or feedbacks or sorry fees and rewards can you establish bounds on those parameters it depends on what you mean with bounds first of all keep in mind they are structured because they have to be typed so if they have the wrong type they will not work what exactly do you mean by bounds in the sense of values so yeah I don't mean like a type bound I mean value bounds well again you have limitations in the sense if you're working with an ASCII world you clearly have boundaries for certain types that you can use and I also of course the question of the computational complexity at some point I haven't talked about this because this is also part of active research so far I'm using compositionality exclusively on the level of composing the representation there are results that show that computing equilibrium is very hard and we will not break these results but in the practice of actually computing concrete games you might be able to leverage also the compositionality because some component here might be computed but it might be independent of that and then you can compute or some component here might compute but it will only affect another component another thing to keep in mind is that as Philip said you can have that a game can just have a function as internals or it can have strategies so in the case of an oracle you can either treat it as a parameter that basically comes from the outside world or you can model it as a stupid function that has no agency whatsoever or you can model it as a protocol that has its own set of economic incentives to work in the right way I guess that would be the case of the centralized oracles where people are incentivated not to lie and whatever the cool thing about this is that then you can start from a scenario where the oracle is honest the very cool thing that practice teaches us is that usually when people design a protocol they have already an intuitive notion of what is the equilibrium where everyone is honest so you say okay you test that you have an equilibrium and then you can basically start bribing the oracle so you can start basically adding incentives to the oracle to lie and one thing that you can do very efficiently computationally is finding a bound that is basically the cost of breaking your equilibrium so you say how much do I have to bribe the oracle to break the equilibrium and then this is super useful because now you can find parameters and since you are starting from the equilibrium that you already knew you don't have to do equilibrium search it's just equilibrium checking you just linearly increment this parameter and it's okay this is how much we are protected and then yet that would be a sort of bound between your model of how expensive would be to fuck it up basically Hi I have a few questions because I've been really listening so intently and I've written some things down so it's okay the first one was could you perhaps optimize a compiler by modeling it with category theory and with your tools oh sorry was that kind of hard to understand could you perhaps model a compiler and optimize a compiler using your tools and with category theory okay they are actually doing people doing this here I think at least trying but honestly this is definitely the outside of my expertise I can't say that you can probably check the research of this professor called Dan Geeka that is using category theory to do compiler optimization so yeah that would be probably the closest thing and that's exactly where my knowledge of it and thanks and then another question and I'm going to speak run it so nobody gets offended that we're taking a long time could you model perhaps an iterated prisoners dilemma with a variable number of agents and rounds with your tool very cool and will you have a release like a function annotated sort of preprocessor language that's maybe syntax agnostic or something that you could add into other code bases that aren't high school based in the future maybe very cool okay thanks for coming