 So, the title of my talk is, stay with us, building a survival proposal for a corrosive digital environment. How could a digital environment be corrosive? Obviously, we have to make it be corrosive. Why would we want to make a digital environment corrosive? The whole point of a digital environment is that it's completely stable. It is. Nothing ever changes. And so the big picture that I want to leave you with is that the purpose of this research, the goal of this research is to say, if we are going to move to much, much larger scales of computation, which I believe we are, we are going to have to give up on our most cherished assumption of digital computing, which is hardware determinism. We're going to have to give up on the idea that the hardware is guaranteeing to do exactly the same thing every single time. And if we do that, we are going to have changes, degradations happening inside our software. And we're going to have to deal with that somehow. And the best way that I can think of to deal with that is to deal with that upfront. Suppose we build in corrosion. Suppose we build in an inherent mechanism that's tearing stuff down and ask, can we design software structures that will be robust in the face of that? And that's what I'm trying to do here. Okay. So I have a famous history of not being able to shut up. So the only safe thing to do is begin with the conclusions. So here they are. Traditional digital computing is ultimately unstable and unscrupable. I already touched on that just a little bit. Best effort computing is the alternative I'm proposing. The hardware does not guarantee to be 100% repeatable. It will try. It will try as hard as it can to get the same answer for the same inputs and the same instruction, but it doesn't guarantee to do it. If it fails to do that, software cannot complain. Software should have been covering its own access. Best effort computing offers inherent robustness and indefinite scalability. Once we give up on this idea that everything is going to be completely synchronous, kachum, kachum, kachum, kachum, and there will not be a failure anywhere in the universe, we in fact now can build computers of arbitrary size. Any actual machine is not infinite in size because infinity does not exist. But we can make any finite size that we like, and in fact we can keep on adding stuff while we're using it. Alright? And so we're actually working on building that. This here is a T2 tile. This is one of a unit of computing. It's got six connections around it. And the idea is you take these little inner tile connectors, and if I can get it oriented right, you stick it into one edge, and then you can put another tile next to it, another tile next to it, you get a whole row. Up on top they're staggered, offset, so you end up making a brick wall. These things share power, they share data. We have north of 150 of these now built, waiting for software loads. How much? How much money? Not counting my time at zero, it's somewhere on the order of $150. One time before zero, right? Say, well, I chose, right? You make a test. Say yeah. If you can show me that you will use that, we should talk. And I'll circle back around to that at the end of the talk as far as where we want to be. Okay? So, artificial life. This is why the reason I'm speaking here. Artificial life can ensure the lead the way in best effort multi-cellular programming. My claim is we are essentially going to recapitulate in a digital stylized form much of the history of the evolution of life in order to build up this new computational stack to deal with best effort hardware. Living systems never had the guarantee that everything was going to be perfect. They always had to deal with everything going. We're going to do the same and the design solutions we're going to get to, things like cells. Things like cells that reproduce for robustness, for performance, to fill available resources. That same thing is going to happen like that. Okay? So, the specific work I'm talking about today is called the C214 protocell. A year ago in Tokyo, I presented the C211 protocell. This is three numbers better. And I'll explain to you what the difference is between C211 and C214. There's a lot more left to do. All right. So, today I want to introduce the idea of software living technology. Living technology versus artificial life. Living technology versus artificial life. What's the difference supposed to be? Living technology actually cares about being useful for society. So that someday somebody might even pay for it. It doesn't? No, I don't think they have to use it. What makes it anything different than an artificial life simulation? We can debate that question. I was going blue-marked with those. I was coming secret. Then you told me that infinity doesn't exist and you were instantly my friend. Well, the slogan is infinity is brain damage. So we may think it exists, but we don't need to look at ourselves. We really are. All right. So I suggest that we have not just a scientific interest in exploring the meaning of life and using digital systems to make models of life, all of that stuff. We have an additional obligation to society to help develop new computational architecture that will scale better than CPU and RAM and hardware determinism, and it will not suck at computer security like CPU and RAM and hardware determinism manifestly does. Okay. So today, this, oh, and then the couple going forward is for next year at the A-Life 2020 conference. We want to have 150 or more of these in a grid, maybe two meters by a meter and a half on the wall in the lobby, or we're negotiating, we're talking with conference organizers, as we speak, and I would really love it to be running your code. So the big picture is there's at least two big attractors, two whole styles of computation, and they couldn't be more different. I'm not going to go through every box on this thing, but roughly the middle column is what we have today. We focus on algorithms getting from input to output. Important point number one, the algorithm must be correct. Given that it's correct we want to be as efficient as possible and yes, we want to be as robust as necessary. And what I suggest that the alternate approach to what I'm calling the indefinitely scalable approach just rotates that one step. We're going to say it must be robust. In other words, it must put up with whatever challenges get thrown at it in its typical environment. Given that it's robust, it should be as correct as possible. Yeah, it should try to get the right answer. That's not the most important point, but it's a very important point, and then finally it should be as efficient as necessary. That's the change in mentality. First be robust, then as correct as possible, and as efficient as possible. Both get the same things, they just have a different set of emphases that lead to very different architectural designs as suggested by all the other rows of this table. And again, what we have today, is the master of the universe. The programmer is God, nothing happens except what the programmer says. The programmer can write something to memory on step one, and read it back on step one trillion, and it must be the same. The indefinitely scalable process is there's going to be many, many similar things trying to cover for each other, or compete to do the results, whatever it may be. It's member of the team versus master of the universe. And again, this is not for me, because everybody in a computer science talk needs to have a deep, annoying picture, right? There's a few others, but they're not as good. And in 1948, he was saying, you know, we're going to have to move beyond hardware determinants. We're going to have to build a model that allows malfunctions with low model builders, and we're going to have to care about how long the program is. That's crazy. And now it's been approaching 80 years, 70 years since he said this, and we're still doing it the same way. We haven't listened to it. So I feel like what I'm trying to do is affirmative action for what von Neumann said we should have done seven decades ago something like that. And there's obvious reasons why we haven't done it. It's hard. And we have all of these design assumptions, hardware determinism, binary numbers, universal computation at a very low level. All of these design decisions interact and support each other and resist giving up on determinism. And if we give up on determinism, we have to give up on stuff that we didn't even imagine was an assumption. We thought it was obvious. There was no other choice. There are other choices. All right. So, what I figured out and only took a decade or so was that instead of just saying the current model of computing is bad and wrong, we need to come up with an alternative model of computing that's good and right that we can head toward rather than just heading away from where we are. Because there's way too many directions away from where we are. And the suggestion is we should head towards architectures that are indefinitely scalable. That they never run out of RAM. They can't have a single CPU because you can only fit so much stuff in the light cone surrounding a single CPU. Period. Just as a matter of physics. Okay? So, if you take this really seriously, if we're going to come up with a computer architecture that we can grow to arbitrary size without ever saying, whoops, 640K of RAM were done. Whoops, 64-bit address space were done. If you can think of architectures that have none of those limits that's what indefinite scalability is about. That's what the T2 tile exemplifies and that's what I believe is sufficient to drive the development of artificial life for useful computation. We need kind of an entirely new computational sector. So that's why this research project has taken a little while. We've made a ton of progress but really the idea is artificial chemistry is the physics. You imagine making some level of commitment to saying this is the kind of state transitions we're going to support. We'll build in some kind of programmability some kind of customers can say, well I want elements that make things grow bigger or I want elements that make stuff look like flowers or whatever the heck it is and they could have that. But then even that is going to be sort of an unaware level. We're going to control access to changing it and then above that we'll have the sort of chemistry level where it's just reactions happening and that will be relatively a free-for-all within the rules defined by the physics within the rules. If it's not deterministic distributed architecture why is it not deterministic distributed? Because it definitely scalable forces us to give up on determinism and to give up on central processing. So that's how these things work together. So local state transitions spatially distributed, this guy says I want to do something he looks at his spatially local neighborhood and says well given where I am now I want to do swap these two guys and change to blue and they do it. So those local state transitions is our programming model. That's what we have to do. We have to figure out how to develop a number of elements and give them state transition rules. And from one level now it's just a software problem. Like all software problems are just software problems. But it's worth your life to actually try to get it right and in fact you have to try stuff because you don't understand how the interactions between one set of decisions you made are going to work in the company. And that's just as true with traditional computing. It's just normally you have this much bigger chunk of where you believe your God where everything does what you say it does. Before you get to input and output and now you deal with somebody else's stupid assumptions in the whole industry, the artificial biochemistry, when we get to these sort of proto-cells that we can now start doing a higher level organization and instead of thinking in terms of atoms and molecules we'll think in terms of cells and multicellular organizations and we'll go on up. This is called the event window. This is what the world looks like to an individual atom. It sits in the middle at site 0 when it's turned to go its transition rule is going to look at any of those 41 sites including itself, make any decision it likes and update that window not just itself but rewrite the window however it likes in its image. Well, rewriting in its image is not a good idea. But this is it. This is all that a local element gets to see to make its transition. Alright? So how are we going to make these transitions? I mean, obviously this grid like layout feels like a cellular atom. It seems like a cellular atom. And it is a cellular atom. But it's not a conventional one. It's not synchronous and there's no guarantee you have to terminate this. What we do instead is we pick a random site and say okay it's your turn to go okay it's your turn to go and there can be zillions of individual sites going on at the same time as long as none of their vent windows overlap. So the way we cannot write a state transition table for this. There's something like a thousand, several thousand bits of state here is the transition table with F2 and 3000 rows of the table. So instead we write code, we write programming language code. We put out languages to help us do that. This is a snippet from a program that defines an element called Swapline written in the language Oolong which we presented two years ago, three years ago or something like that. You know, even without knowing Oolong, Oolong was deliberately designed to look regional, we're familiar with, I get it, a site name. So those are the points in the event window. So it's a loop that's looking over the event window making some kind of decision. Getting the coordinates greater than zero and so on. And checking each atom to see is it a Swapline. And the goal of the Swapline mechanism is you have a vertical line that's heading east. But since it's not synchronous, the thing is not going to go chunk, chunk, chunk, chunk, chunk. One guy is going to get it to go before the others. So he moves ahead and the idea of a Swapline is he looks at everybody who is behind him to see are there any Swaplines around me that haven't caught up with me. And if so, I'll just wait. So what ends up happening is whoever happens to be the back man works his way forward and then the line goes forward. So what you see is this little raggedy line gradually moving east, never going more than a 45 degree angle. And the Swapline ends up being useful as a component of many other more complicated molecular systems up through and including this thing that reproduces arbitrary objects by passing Swaplines through it and copying the line when it finds it. This is a lot of code to express that. It works. It's good. But since then we've developed second language again which was presented last year called SPLAT that is based on spatial patterns rather than traditional sequential code. So here's the same program written in SPLAT. It's an element of the Swapline same thing, same color, same symbol. These are rules. Left-hand sign, arrow, right-hand sign. What's S? Well S is a site that has a Swapline in it. So if we have a Swapline and that sign always represents me. So if I have a Swapline to my left I can replace it with empty to my left and me. That means leave that site alone. Don't change it. So the net effect is that if I have multiple Swaplines in a given row they compress down to just one. Because that's really not supposed to happen. We really wanted to have an individual guy moving down. But then here's the trick. If I have a Swapline behind me above or a Swapline below me I do nothing. Don't change it, I don't change it, I don't change it. What does that do? What good does that do is the fact that this rule matched means the event is over. The way Splat works is it considers the rules one at a time and the first one that succeeds that's the end of the event. So if we have a lagging Swapline this matches and we're done. If not, me followed by anything turns into anything followed by me. So it accomplishes the same thing but it's much more concise and it gets at the spatial relationships that traditional programming languages really are bad. So that's it. So we take big leap from Swapline to the C211 memory. This is what I presented last year in Tokyo. Each of these things is a proto-cell that has a light blue intermembrane and a darker blue outer membrane and a bunch of goo inside. And you let this thing run and these things vibrate and move around and tear each other into parts reproduction and so forth. Now in particular these guys were really messed up and they had some uncontrolled growth problems so eventually the world end up being filled with this seeding cauldron of Jabba the Hut cellness just because of bugs. All of that stuff could have been fixed in principle if need be but there were other issues we could see 211 memory that we wanted to address instead. I'm running my short on time so I'm going to rush on ahead. Two of the issues were the C211 memory existed in a vacuum. The world was completely empty except for other cells. And the goo on the inside that cancerous goo was not very useful for making future additional more complex computations. So we have changed in the 214 model to adopt this corrosive environment. We have these elements called drag which stands for dynamic regulator and without going into the details dynamic regulator is empowered to erase stuff next to it no matter what it is. It rolls a random number and if it's just feeling like your number comes up, you're gone. Doesn't care whether you're part of a cell membrane, doesn't care if you're the prettiest cell whatever, you're gone and the rest of the computation has to handle it. That's the corrosive environment. Why don't we just kill off all the drag? Well because the other thing drag does is generate reds resource atoms and that's the only way that resource atoms are created. So if you give up on the drag to get safety, you have no resources. So we tie creation and destruction together in one element called drag. And so that's the model that we've lived in. These are the drag reactions in the details and then there's the three-step development. These are just three engineering improvements that we discovered when we put C211 in a world full of drag and watched what happened. It wasn't great. C211 was not prepared to deal with it. It turned out there were a variety of cases IM intermembrane OM outer membrane there's supposed to be an invariant that IM should always be surrounded by OM and that invariant is violated here. Why? Because drag came along and chewed off a little bit of it but it turned out because the rule for C211 wasn't expected yet. It's a pinning state. So the whole rest of the cell started flailing around in a little spot that never moved. So there were several things like that that we had to fix but in addition we wanted to say how could we do it even better and we'd help with this idea well, you know in the drag physics it's a sin to kill a drag. You're not allowed to erase a drag. Nothing stops you from doing it but if you happen to erase the last drag you just killed the universe. So it's a sin to kill a drag but that doesn't mean you're not allowed to erase a drag. So here we have a rule this guy is an outer membrane and he looks for drags anywhere in here and he looks for empty spaces out here and he finds that he pushes the drag further away. Which means it improves the survivability of the cell membrane a lot. And we took that one step further and again you can read about all this in the paper where in addition now the cell membrane there are little atoms that float around outside the cell membrane and act as patrols and when they see drag they use the cell membrane themselves and the drag to figure out a line which way should I push the drag to get it further away from the cell membrane and that works great and here is our results this is the survival graph 100% means survival rate 50% of the population was still surviving at 43,000 events and so forth and fun so far our C214 more than half of the populations were still surviving more than half of the individuals excuse me one cell in each run were still surviving and we got to 500,000 events which is where we started so we got better than a 10 time increase in the survivability and I'm out of time so why don't I show this while we take one question and let other folks in any case thank you so much any places where things don't work well and it seems to me we're relying on state areas not programs but programs would be in those machines so the programs can go on as well so how would you handle that? so the idea is you're going to have a layering of stuff that is extremely hard to change like the hardware then stuff that's fairly hard to change and that's going to be the laws of physics they're actually running out of firmware they're running out of flash and so forth can that program get corrupted? it absolutely can all we have to fall back on is to invalidate ourselves reboot and we will then take new copy from our neighbors automatically but there's no one solution you've got to keep solving it again at each level I'm not really an A-life person I'm kind of new to this and you're interested in analog processes and you're interested in stock elasticity why do you use analog confusing? I don't think analog and stochastic are welded together you don't need to use analog to use probabilistic or nondeterministic stuff and for me the distinction between digital and analog is totally a matter of degree if you take digital and say like these brown spots these are resource ads there's a amount of energy you know, shoveling between norms and wants yes and when you see how hot these things get now you say yeah, absolutely and my response is once we know what we want and we can optimize much harder than we can right now because we can tolerate some degree of error but by going all the way to analog we have to then build back in digital like recovery mechanism so it's going to go one way or the other just to quickly because I'm sorry I came in late I'm at another conference as well I'm interested in making chemical computers but not simulations of them literally chemical computers but I want to use cells which doesn't have addressability but I love the fact you're mentioning the need to go in sequence anyway I'll cut to the point can we throw out a little bit more in between can we throw out your computation being done in the CPU and instead use your architecture to address a cellular grid and a bit like Alan's question we actually embody the computation chemically basically in a jelly and can we use your system to interface and program the cells so the glib answer is yes I am not interested in doing that anytime soon because the impedance match the amount of hardware you would have to provide me the amount of physics you would have to provide me let's say you have that already do you have arbitrary nonlinear mappings of state to state that we can do low quality well then maybe we should talk I'll have to run away believe me it's really interesting I can see you hijacking your firmware I would love to say could we pop this digital stuff out and put goo in I think there's a reason to want to keep digital alright I'll use more than my time