The Actor Model Explained by Carl Hewitt, Erik Meijer & Clemens Szyperski

[00:00:00]Eric hey Charles how you doing great man we're laying that next rocks yes yes what's going on wonderful okay so here we are it's kind of you know three academics um Clemy spki calll you y and what we're going to do is we're going to talk today about actors everything you always wanted to know about actors but we're afraid to ask excellent we can now ask the questions to the guy that invented actors because actors people talk about actors here actors there but they use it in a very informal sense but Carl has you know has a very kind of you know precise meaning of what an actor is and that's what we're going to kind of you know suck out of his brain today and glus is going to help me with that will suck yes that's right okay good job of it too so so so Carl what is an actor it's not somebody that's kind of in a TV show or like us right now no the the the actor is the fundamental unit of computation as the fundamental unit of computation it has to embody ody three things okay it has to embody uh processing because you got to get something done it has to embody storage because you have to be able to remember things and store things and and it has to be able to embody Communications so an actor is the fundamental unit the Primitive unit that embodies all three essential uh elements of computation I would spake here sir okay I started to count with one yes okay you're getting old yes yeah too long out of the Netherlands you know it's like d yeah so so now okay so this is great so an actor embodies these three things now people often kind of you know when when they talk about actors they talk about like you know mailboxes and message cues and concurrency and locks and so um how does that fit into this picture right that's a very good question question um the first thing is that um we have to be reminiscent of eio Wilson eio Wilson famously s said that one ant is no ant right well one actor is no actor they come in systems yep and so they had in order to come in systems they have to have addresses so that one actor can send a message to another actor and there's no reason an actor like factorial can't have an address for itself so that's the way you implement recursion okay okay then but then the actors are very abstract because Beyond this okay all we have a certain fundamental properties of actors for example suppose the first property is that everything is an actor okay and then you say an actor has a mailbox well a mailbox is an actor so now the mailbox needs a mailbox y this is the disaster so now we're going down to Rabbit Hole we're going down the rabbit hole that's right right so where does the recursion end with the axioms okay good axioms I love right yes I love aums first yes yes so what are the aums the first axium is when an actor receives a message okay I'm using yeah I'm using right yeah Roman numeral what can it do all it can do is it can create some more actors it can send messages to actors that it has addresses before and it can say it can designate what it's going to do with the next message it receives and that's it everything else has to be done out of that okay so the third thing again just the third thing is you designate what you're how you're going to handle the next message you receive okay good that is does have that something to do with continuations uh well no because continuation was an old idea for the vman machine continuation is the Lamb expression that you execute after you finish doing the current one okay so that's a that's a single threaded kind of idea okay so whereas whereas this this this has to do with concurrency if you're a checking account right and you have a balance of $5 you might receive a a deposit message was $6 now your balance is $11 right so you say when I process the next message I process it with a balance of $11 I don't change any of the names I have now I'm just the change applies to the next message that comes in okay so so then I I have I have like a a clarifying question so here you say that you know so when how does because here it says you know you you you kind of you know decide or designate what you do with the next message but this message Loop here or there's no Loop but where where is the kind of are are can an actor run do things many things in parallel or can it only kind of you know send messages to the other ones create new ones and and kind of you know okay and anomally to First approximation it processes one message at a time okay but implementers know how to pipeline messages in certain cases and in the case when you're in the case when you're going to process the next message in exactly the same way you're proc processing the current message somebody like factorial y you can do all of them at the same time so factorial can be processing arbitrarily many messages at the same time but but conceptually you you kind of you know you process one message at a time and then the implementation can kind of you know make that more concurrent that's right yes okay so so is is that okay if I kind of write that down to because I'm looking for the conceptual model model that's right so we are looking for the conceptual model so conceptually okay so now of course the the question put an asterisk on that because the the loopholes are large okay so um so I I'll quot yes right it like that so now the the the question is what happens if an actor sends a message to itself you know maybe directly or indirectly would it go into a deadlock well okay okay the next thing you have is is is the notion of a future ah okay good future we all have a future we all have a we hope right the idea of a future is that you can create an actor for any result while it's it's still being computed you don't know whether it's finished computed or starting whatever but you can now have an address for something like when you buy a future for a bushel of wheat okay yes then it's for a bushel of wheat not now but in the future okay and if a drought happens then the future will break and you will get an exception instead of a bush of weat well these Futures are the same way but they are actors you pass them around so for example you say future a factorial of 100 million and you think it might take a long time to compute the factorial of 100 million but get the future immediately okay and you can pass it around and you can store it and you can send it in messages so now if you want to send yourself a message back you you you can you can put the the the message to be sent to yourself in this future send it to yourself and now you don't deadlock okay good all right so that sounds good so Clemens yes I'm wondering um if we um designate what to do with the next message um how is that different from creating a new actor ah because I'm the checking account and I have a balance of $5 and I get a deposit of $6 right that if I created a new doctor a new actor with a balance of $11 that would be no good because they expect the old actor to have a balance of $11 all right so designating what to do with the next message is the next message to me that's right yes and and and also I would say the the way I kind of look at that climat is that because I I think where that say each actor I didn't write that down that each actor has an address that I can kind of you know talkes s messages to so it's like you know if if I if if the if the actor was a chicken and I chop off his head you don't get like a copy of the of the of the chicken without the hat and the other one still has its head so I think the the actor actually kind of you know yeah but the actors are very powerful chickens yes the actor has to agree to chop off his own head yes exactly that's very he all you can do is send him a message saying you know please commute sauki okay and it can send back an exception saying I don't think that's a good idea so would then the address of an actor be equivalent to its identity no because you can have one actor one address for a whole bunch of actors if you're replicating behind the scenes okay and one actor can have many addresses okay that forward to one another so there's a many to many relationship among actors and addresses and is act identity discoverable what would you think you mean by identity if I hold if you can I actors as values no all you have is addresses so you compare two addresses as to whether the addresses are equal or not and that tells you nothing so then how do I know at any level of looking at my system whether I have one actor or multiple actors behind an address you cannot tell I cannot tell you cannot tell because for example when you do a search on Google Google has one uh address yeah right it's not it's it's not the same Google everywhere who's processing your search request even though you sent it all to go to to to Google google.com and the same is true for Bing by the way same is true for Bing that's he meant Bing that's I meant Bing I meant Bing that's right we're kidding right yes of course that's just beta reduction right that's right but talking about that can you have two addresses that kind of you know have that are kind of you know proxies to the same absolutely right because one of them you might have one actor that just forwards messages to another actor and you can't tell okay whether whether you're talking to a forwarding actor a proxy or you're talking to to to somebody behind the scenes because all you can do with a message with an address is send it a message period so now now you can use encryption encryption and you can still do Authentication and if you create an actor and have an act an address of an actor you created you can have pretty good idea yes who that is so so now I I have a question about that like you know to to continue a little bit on what what CL said it's like let's talk a little bit about these kind of addresses of actors and about what you say you know like create more actors because how can you know how can how can you be sure that I don't kind of just cook up some address you know I kind of you know randomly generate something and I I say okay now I'm going to send a message to this address that I cooked up out of thin air so where do these addresses come from and how are these actors created okay well basically uh within a system uh like for example the CLR which enforces uh the address Integrity the Integrity of addresses you can rely on the CLR between the machines you use encryption so what you do for your address you send it out you encrypt it and when it comes back if it doesn't decrypt as what of your addresses it's no good okay so you're saying it's like in the CLR I cannot take if if everything is implemented correctly I cannot take an integer and kind of cast it to an object that's right okay and so so in that sense addresses seem to be like capabilities that's right yes yes they they are in fact you know the the original work by Dennis and Van Horn was one of The Inspirations for the actor model except that they had a very cloy way of doing it because they had no protection within an address space they had to put the the the magic stuff out to the side and it was just incredibly awkward if you can maintain the Integrity of the of the addresses you get capabilities for free an address I think is a much better name for for capability because it indicates what you have the right to do namely send it a message that is the only and fundamental capability the other the other inspiration was the work that V Surf and Bob con were doing on the internet okay with packets we say packets are nice but we need messages but these messages will be obey the same rules as packets for efficiency reasons so if I send Eric two messages in a row I send you M1 and M2 you might receive M2 before you receive M1 because it's more expensive on the system to try to enforce that constraint and that's why the US Mail system says if I drop two messages in the mailbox for Eric he can get them I Dro one in today and the other usually that is the case actually yes right that's right random a that's right so so so let's talk a little bit more about that I'm going to kind of draw the picture here so we have two actors that's you know let's say actors a z and A1 and they and let's say that this one sends messages to to this one yeah so you said that if this one sends message zero and message one that they can arrive in any order that's right um Can it can can messages be dropped can they disappear or are they always guaranteed to arrive it's best efforts best effort so best effort now so what does best efforts entail okay what if you're going across machines if you're going across machines best efforts entails that you that you're going across machine so you'll persist it to some kind of stable storage okay so that you can resend the thing if you don't get an act back for acknowledgement back for the other thing on the other hand if you take this message and persist it and a terrorist blows up this machine the message is gone even though you persisted but but but let's go back to the kind of basic aums right because there we don't we didn't talk about like persistent and so on so so the in the in in in this kind of conceptual model the the messages are you know is this channel reliable or what is what are the properties of the channels between the actors there are no channels or channels and this is very important good so there no Channel no channels no channels ah no overhead get those directly you don't have to go through some intermediary called a channel and un like things like communicating sequential processes and the process calcul and all those guys where you have to use an intermediary intermediary has a terrible problem because if you have two guys trying to get something out of the channel okay only one of them is supposed to get it so you have to go through a large amount of overhead like a something horrendous called a two-phase commit just to get your message right yes so the actor say no no no no this is very bare Bare Bones you can Implement a channel okay with a put and a get message to it if you want one but that's not part of the okay okay channel would be another actor a channel would be another actor okay and suppose you wanted to actually sequence these two guys okay well then what you do is you make another actor called a sequence m0 M1 and you send the sequence to this guy okay but I I'm I'm still so so and these two guys can be Futures so they can manifest themselves whenever they're needed so I'm I'm still so I understand I was my apologies for using the the word Channel but I mean whatever there must be some kind of you know eer or whatever where kind there no either or photons but these things must communicate so I was I was looking for what are the properties of that you know of the communication between in in in in the very abstract so so so so it tries very hard to deliver every message but can it duplicate messages no a message will be delivered at most once at most at most once okay that's right one or zero times and in arbitrary order and it could take a long time if this message goes through a mail server in timbuck 2 it might be like one of these messages to Queen Victoria that's discovered behind a closet in the in the mail in the post office when it's torn down and is delivered 100 years later yes or like you know Message in a Bottle kind of you know floats Over the Sea flows over the sea that's right yes that's right yeah and so another thing that you often talk about is nondeterminism and you already kind of talked about that when with channels you know that two people have to kind of get it out now there's a Race So how does and and Arbiters you know that's another kind of beautiful thing so how does that fit in this picture the first thing to do is and this these are and just like these are not actors on TV the Arbiters are not like in a tennis match right they're they're they that's right they're not but but the ones on the tennis match be made out of these yes the ball is out right well that's the thing about it we'll get to it just a second the Arbiter does decide okay yes and and and there's nothing before the Arbiter decides that the Arbiter actually now so we want to distinguish between non-determinism and indeterminism okay non-determinism is what we got with the original t machine that's when you flip a coin okay you flip a coin it comes up heads or tails if it's heads you go one way if it's tails you go the the other way right so that's a kind of thing that you had on the turn machine the non-deterministic turn machine Y and it's not sufficient okay because it doesn't give you indeterminacy indeterminacy is what happens when things are things are decided by by working themselves out it wasn't somebody flipped a coin to make a decision it was how it worked out okay how can this be well if I'm sitting here sending might say suppose I start off I'm very simple actor I have a count of zero and I start off and I send myself a start message and a stop message y okay if I get a sorry go message and a stop message so let's write this down go message and a stop message okay and we we come in with a start message yep so when I get a start message I send myself a go message and a stop message if I go get a go message I increment the counter by one and I send myself a go message if I get a stop message then I stop and Report what the count is okay now this is something that no non-deterministic turing machine can do because this thing can stop with a account being arbitrarily large it wasn't somebody decided how big the count was going to be the size of the count was dependent on how long it took this stop message message to arrive nobody ever flipped a coin it was just how long it took so this is a way where you move okay from non-determinism nondeterminacy to indeterminacy and is it does that also have to do something with the fact that this message kind of you know is is in some sense like you know out of out of the system that it kind of interacts with the environment and it's not like the closed right because that that was that that was where we started off yes that there there's some something called the state yes the state of the computation which is fixed yep and that's why it's possible to prove and my colleague Gordon Plotkin gave a very nice proof of this that if you have a state Machine model of computation then it has to have bounded nondeterminism okay whereas this has a configuration model we have the local state of this guide the count but the configuration out here has a stop message that's traveling in photons he's not sitting still anywhere so this is a configuration-based model of computation which is more powerful because it incorporates communication than the state-based approach yeah so so so that is an interesting thing like there's there are some like recently A lot of people think that like touring machines are what defines uh computability but but you're saying that really interaction with some kind of you know open environment is kind of you know it definitely changes what a computation means because that is the difference between not determinism and in indeterminism is that correct that is correct yeah and Robin Milner cabbaged onto this in his touring lecture in which he pointed to the actor model of computation as the in inspiration for his starting to develop the process calculi but there the emphasis was different he was emphasiz he wanted to have nice algebraic equations right yes so he put in the channels so he could have his algebraic equivalences right but the actor model didn't because the actor model wanted to remain faithful to physics as its touchtone not algebra and the physics says you don't put in an intermediary because it's a source an necessary source of overhead MH so another model that's also inspired by physics is petrinet so how do actors relate to petrinet ah good question petrinet also did not relate to physics so let me just briefly explain what a petrinet is so a petrinet is a is is a game played with tokens and and uh what happens is you have things called places and Transitions and you can put Pennies on the places yep and if all if if you have Pennies on all the input places of a transition this is the output place you can take both pennies off simultaneously and put one penny on the output place okay well we're s of follow dyra and call upon the law of the excluded Miracle the excluded Miracle is that the these two pennies at different locations can both disappear at exactly the same time because this one might actually be the input place of another transition over here and this one could be the input place of another transition over here so you actually have to steal both of these at the same time and the actor model will not let you do that okay so you're in in this case you're saying these kind of tokens would be somehow entangled because right and you're and that's something that you don't allow not allow so in the actor model can you not express synchronization uh well oh sorry no no it's okay it's okay so what is your name welcome welcome welc come around here just come around here why don't we push the table yes hi I'm sorry for barging it like this no that's okay did you go go for the camera right here we go right my name my name is Shaz and my question was uh um the what what what you described about Patrina is essentially synchronization and you said that it cannot be expressed in actor model so I was wondering can you not express uh synchronization in uh in in the actor model yeah well it would be a disaster if we could not right so so we already know what the end but that we need to explain it yes let's think about the checking account see checking account is not something you can do in functional programming because the checking account is sitting here and there can be many parties out there we don't know who who's going to make the W next withdrawal from the this checking account from some ATM some place on the planet so the way the actor bottle deals with this is an individual actor processes one message at a time but it's indeterminant which message will withdraw will will arrive next so you might have somebody in Tokyo who's depositing $7 while somebody in England is taking out $8 and it might only have a balance of $2 and it depends on which the order in which the messages are is indeterminant and the outcome will depend on that whether you get your money or not but in some sense you're saying that the sychronization is kind of built into the rule that one message is handled at the time that's kind of the fundamental where you know the the Primitive point of synchronization that's right yes and that's where the Arbiter comes in yes okay good because I love it's like the Miller C element favorite kind yeah my favorite so here is here is the Arbiter and I have examples of this um there's a very I should put in a plug there's a very nice volume coming out commemorating the 100th anniversary of the birth of of Alan Turing okay yep whose machine cannot do this but we commemorate him because he was a great man nevertheless yes and he like tapes yes and in there I actually have pictures of some of these Arbiters and examples in that volume and you can already order on amazon.com and Hector zenil is the editor that volume and Roger Penrose wrote the the preface okay so what's an Arbiter an Arbiter is something that you cannot make out of straight and Gates and or Gates and other Boolean components okay it has the following property it has two inputs i1 and I2 and two outputs i1 01 and O2 so here's the deal you start off with both these zero you're allowed to put in both of these at the same time but only one of them will come out as a one okay only one of these things will rise from zero to one not both of them just one and the bow is in or the ball is out but it cannot be both it cannot be both that's right yep and so so so so so this is the magical magical circuit it consists of Cross coule Gates inside it it's a very small thing our computers are becoming absolutely Chuck full of them our multiprocessor systems have them which makes things indeterminate and so now it's be more difficulty bug our programs because it used to be that we put the same input in and run it again and get the same bug now we put in the same input okay and it does something completely different because all this indeterminancy inside so so can I can I ask um two questions like one is like isn't this thing kind of behaving like flipping the coin where it says you know like the coin is like heads or tails it's not for one thing it can it it we don't know how long it's going to take when you flip a coin okay so okay so so this can take arbitrarily long to decide yes but but but in practice it always it's it's like it's like the Arbiter at the tennis match we said we were going to make him out of Arbiters the Arbiter of the tennis match can take as long as he wants to make his decision whether the ball was in or out but he must decide yes yes okay so but that is an very important property that it can take unbounded time to that's right but with a exponentially decreasing Pro probability so the amount of pro the probability that it hasn't decided yet goes down exponentially so in practice these things work just fine okay and so my second question is like if we if we if you look at these things if you look at the network card inside your computer and two kind of you know packets come in at the same time is is there an Arbiter kind of you know in your network cart in your PC or how does that work how does that thing decide which message came in before the there is an Arbiter okay but it's an Arbiter between what's going out and what's going what's coming in is where the arbitration is taking place because the place where the Arbiter was originally invented was when they took the turning machine the Von noyman machine and they hooked it up to the teletype is now you have a terrible problem somebody presses a key but the computer already thinks it knows which instruction it's going to execute next right so you you you want to have a a piece of code to process the character and a piece of code to do what it was going to do before and now you've just invented concurrency and you need an Arbiter to decide which piece which Pro which which value the program counter to pick next is it going to be from the interrupt Handler or is it going to be from the the program that was running before yes but but this is interesting because you mentioned dexra before but didn't dexra kind of you know do a lot of stuff with interrupt handlers in the th kind of this yes and then and then he forgot about it or rejected it and then ideology took its course ah okay he could not bring himself to believe in unbounded nondeterminism he said to himself there must be some bound and then he convinced Tony so in the first first version of communicating sequential processes the semantic specified bounded non-determinism now unfortunately this is a disaster for concurrent systems because if you're a server and and and and Clemens and I are both trying to send input to you right if you can make an arbitrary choice you could always choose me of course I would of course you would right but with an Arbiter here with an Arbiter which produces the unbounded nondeterminism so then in the second version of CSP the semantics were changed because they wanted to be able to prove that a that you could actually make a server using CSP that would work and not starve customers okay so this actually has a practical import to it okay so so I'm I'm still fascinated by these addresses um yes because like how do you kind of you know because we said like and and about like the the communication between two actors because how do you know how do you find you know because that is something you abstracted away from is that you know given an address how do you find the actual actor because like on the internet there's DNS right you know if I have the I can find the actual machine how does that kind is or is that something that we don't need to know in this kind of abstract the that's right so the actors are in fact very abstract any implement ation that obeys the axioms is okay okay and and so that that's the achievement of abstraction is is is to get up to the next higher level where you can work at a higher level and don't have to be concerned with lower level things like locks like cues in front of you your actors ET all these lower level implementation things but then they get they also give and this is the thing that's taken this you the longest time lots of opportunity to to do good engineering to optimize mhm yes and this is becoming extraordinarily important with the many cores y because as soon as you have a thousand cores on your on on on your chip the world has changed the programmer who writes the program now knows nothing about the environment in which it runs it doesn't know what the load is it doesn't know how many cores there are it doesn't know what its priority is it knows nothing so that the code now has to be written at this higher level of abstraction so it can be adapted at runtime to the current circumstances yep so so so Clemens I I have a question for you to tie this because you wrote a book on software components indeed yes exctly and and and that book is also available on amazon.com of course well let's get it let's get your name on here so yes yeah all right um so so one of the things that you know um what what what what I like about this model and for example what I don't see in a lot of the discussions about rest is that this really kind of you know gives you it's like very kind of abstract as as Carl says about what these things do but they don't really talk or how how the mechanisms work but they don't talk about anything about what happens inside except for you know it can designate the what to do with the next message so is where is when you talk about software components you talk much more about like the interfaces and the behavior of the kind of you know what happens inside so how does that relate um is is that like you know a complimentary view or um and in the in in your um components you also talk about like callbacks and so on which kind of you know has the same kind of notion of Deadlock so can you kind of elaborate a little bit on that well so I view actors as a computational model that basically allows me to understand how things behaviorally unfold and come about um and in that sense I think it's orthogonal to theories of composition where you go and say if I have two subsystems and I want them to interact in a way that I understand and only partially understand what are systematic ways of constraining the composition of predicting what would happen if I compos um and I should be able to do this over many different computational models actors being one of them so so that's a good question so why I mean if I look at this I think you know why would I ever want a different computational model because this to me has like and and I'm not saying that because Carl's here but this is like it's like it's like it's like a little bit like you know category Theory it's like if you want to build something minimal this is going of all you need and nothing more and nothing less so why would you well so I mean that's a good question I mean that's a very good question but there is a there is a moment we have to be careful because girdle said exactly those same words about turing's model of computation he says he said and I quote this in my paper This is the End nobody could ever conceive okay of a model of computation beyond that of the touring machine this is the famous last words okay right and and but but but there is an art to making programming languages for actors I mean it's very easy to screw it up you can screw it up by violating some of the fundamental principles right and and you can also screw it up by not taking them seriously enough for example uh and there's a funny story here with respect to Dy STP there's a sense in which Dyer got it completely wrong he wrote a famous paper goto considered harmful yep from the actor point of view the go-to is completely innocent yep it's a parameterless procedure call yep okay pure and simple right and we we we have the body right there it's like designate the thing with the next message without doing something is that is that is that not the same as it because just no oh good so let me explain let me explain explain more explain more okay right so then I can explain the relationship okay so but there was a guilty party that the dystra overlooked the assignment command that is the evil party if you're going to have something considered harmful because the assignment command in these many core systems is ex excu expensive it can require a signal to go to the other side of the chip right for a global assignment command which is just extraordinarily expensive and maintaining all this state that you're multiplexing among the cores is also extraordinarily expensive okay so what do you do in an actor system okay is this part this is where the this is where the assignment Camp command comes in what you do is you're processing your message you're purely functional you're purely referentially transparent until you figure out what the response to this message is going to do then you say ah the the answer is X and there's this thing called also you see so for example for the checking account you say the answer is the balance and also also the balance becomes the balance plus the deposit mhm but that's for the next guy that's for the next message that comes that's not for us yep so throughout the the the the the body of our message balance is balance so here we're returning the balance it's expression or language so you don't have to say return you return the balance also you do perform the assignment yeah and so so what I meant is that if you do also with the same kind of value now it's like you know you're you're doing like a till recursive colum which is like a go-to and but maybe I'm kind I'm thinking too far um well right I'm not changing the states but I'm just but here we are changing the states yes yes but if if if if I don't change the balance I wouldn't change the state right so it's it's not a tail call because you're actually changing the state right and um because of optimizations it's also not an event Loop which is the other way to misunderstand things good now another thing that you talk a lot about is inconsistency so I super inconsistent that so this is so so why is it important that we don't try to be consistent or that we don't try to enforce consistency on our world well the first problem issue is we can't so we now have these large Information Systems everybody's got them starting with our operating systems you know whether it's iOS or Linux or Windows we have these or SQL where you work we have these large softt W systems that are chock full of inconsistencies and we have these teams of programmers sometimes numbering in in the thousands managing them and they have to be able to to reason about this and think and you can't pretend that it's consistent because the program manager can open a drawer and says here's 10,000 what we are inconsistence we already know about okay so and and and similarly on the internet the information out out there is all inconsistent right and so talking about truth is just crazy it's like is alive or dead well well that's the well that that was the thing about shr's cat right right well the the cat can be half dead right and mean you can because there was a cyanide in there it was supposed to be an alpha particle right that the world but but if the C particle's gone off and you reach in there and and and and the cat only has a little bit of the cyanide we can res resuscitate the cat okay yes so there are things there are things that are clear that get pretty far up but the fundamental situation is that we don't know much and some of it's wrong y that is that is that is the situation which we find themselves so it's kind of useless to deny it okay because then your an emperor has no close mode and it's also kind of crazy to be in Darth Vader mode to think you're going to wipe them out because you can't do that either y so we have to have and we had this this this this this Symposium which you came down and participated in a very nice then you should tell us where we can download the proceedings yes yes yes so that is in uh robust 11.org good yes yes so so there's a proceedings there and uh uh there's and if you if you look it up it's inconsistency mhm robustness 2011 you'll find a web page and there will be another one and there will be another one in consistency robustness in 2014 and we're just about to post the call for papers for that one great and we have the ability to add text to these videos in the description so okay yes but I like the real time effect it's nice okay all right I don't know you want to finish or I have one more I have a I have a tail call um I'm I'm noticing that um it seems like you are modeling local arbitration but not Global consensus um and you're basically claiming Global consensus would be an illusion because you can't really establish it you would have to freeze the universe basically um while local arbitration is something you can do it is indeterminate but you can therefore locally come to a locally meaningful view of view of world but it may be completely different from anyone else's view of the world that's right and in fact with respect to the other guys out there all you know is what they told told you and they by the time the news gets to you right it could already have been you know they may not even exist anymore much less the circumstances they're talking about so you always have from the other guys you always have old news and now because of Moore's Law old news can be on the other side of the same chip you're on so local is very local very local perfect yes all right well thank you so much Clemens Carl um and I hope that you know everybody now kind of you know really deeply understands What actors are Carl has a whole bunch of papers on his website um and um maybe we'll see um more about this thank you so much and um this was wonderful yeah thank you Eric yes thank you very [Music] much