YouSaid · the spoken record

Leslie Lamport

lines on the record: 42
first: 2026-07-13
most recent: 2026-07-13
sittings or episodes: 1
sources: podcast

Every line below is reproduced as it was said and linked to the record it came from. Nothing here is summarised or generated. Directory · Search · Corrections

“I still think computer science is a great field, and I think there's a lot to be done. And the problems that we solve will change as the future goes forward. I am very worried about all the bad behavior that we enable, but then bad behavior is enabled by most anything. So it's not really our fault, but it worries me. And I really think to the extent that we can figure out ways to modify or contain the bad behavior, that's another good research area. So what am I saying? I've said this great research to Pita. And a lot of it's in the systems area.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“It was all about design and modularity and specifications and verification. Maybe that's exactly what we're talking about as the future for coders. They have to be working at that level, not at the how do I write that little for loop with the, you know,”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“And it's very easy to see that we're going to need a lot of verification tools in order to make sure that program is right. There was a letter in the New York Times recently by Mary Shaw and somebody else about what's the future for coders that made the point that the students really need to understand how to write those programs themselves or otherwise how will they know that AI did them right or wrong. And that's correct. I think, you know, there's going to be a lot of research going on, whether this is a field that you can get a good job in and do the kind of coding work that people used to do. What Mary was saying, you know, is you're now managing more the coding and you're working at a higher level. That's a good job. The course that I developed at MIT in the 19, starting in the late 70s with John Gutag, which was a course about how do you build big programs.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Computer science is in a very strange place right now with the advent of AI and not really understanding where we're all going with this. I think that as far as research is concerned, there's huge amounts of research to be done. And I can't help but think about all the systems research that's lying under all the AI stuff and all the problems that are coming up that make for very interesting systems research. So I don't think research is in trouble. I am a little worried about computer science as a field for young people going to college and should they major in computer science and so forth. And I don't understand the limits of what AI can do. I can easily see how AI can write a little program for you if you give it a specification. I can easily see how that program might be wrong.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Maybe distributed systems, maybe more broadly, thinking about computer science, wants to do important work, wants to have an impact. What would you suggest as kind of a mindset, as an approach? To get started”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“There was a long period of time. I mean, so blockchains were sort of launched with Bitcoin protocol, which actually looks rather different than PBFT and most of the other consensus protocols anyone had thought about to that time. And it took, I think, the blockchain community a number of years to realize that PBFT and the sort of subsequent protocols in that family were exactly the right tool for a lot of the problems that they're trying to solve. But at this point, 2025, it is, I think, very well understood among blockchain practitioners and researchers that really PBFT and protocols like it are the foundation for what those protocols are trying to do. One other thing I'd love to talk a little bit about is just, do you have advice for the younger generation? So let's someone who loves computer science, loves research,”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“I mean, it was when Miguel and I finished the work on practical Byzantine fault tolerance, we thought that at some point people would start to use this. Of course, for view stamp replication, it was a delay of about 10 years before people started to use it. And then along came blockchains. So that was very funny.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“And then even more so, I mean, I would say turn complete, blockchain protocol is like Ethereum, Solana, et cetera. They're almost like literal implementations of the fully general state machine replication problem. They're not trying to be kind of a specific application of state machine replication. They're trying to actually just implement it in full so that then a specific smart contract can then be in some sense a special case, a special instance run in the general sort of SMR protocol. These blockchain protocols are in some sense one of the more literal embodiments, I think, of the general state machine notification problem that we've seen to date, which is super interesting.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“I guess today is a very common understanding this separation of different layers of consensus and execution. And it's really cool to see that these are kind of ideas that, again, evolved from these work from the 80s and 90s.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Abstraction. I think it was just sort of, in a way, obvious that you wanted, you know, you mentioned statements. Whatever it is that you're doing, that's just the thing. And you just think about the order, and this is operation number 25 or something like that. So I think it was very fundamental, even in VSAM replication to what we were doing.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, I think that, I mean, that was there from the start. Of course, we were thinking about a file system when we did view stamp replication, but it was always clear that we really weren't the application. We were actually the piece that gave the application the right information. And so we didn't really care. We just rode into the ledger what the operation was that was being requested. But we were not in the least bit interested in what it meant to execute that operation. So it just seemed like a good separation of concerns. And I think even in the beginning, we understood that you wanted to look at it that way because you didn't want to limit yourself to one application. You wanted to find this generic thing that would work for many applications.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“The other thing I wanted to ask you about PBFT, or one of the things that I really was very helpful for me when I read these papers, is not only the replication protocol itself that has certificates and 2F plus 1 that we talked about, but also kind of this observation that once you have a consensus protocol or a replication protocol, you can actually run different types of execution engines. So you mentioned a file system as one example, but you could run other types of services. So maybe you could talk a little bit about kind of this view of a generic service as a replicating service.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Certificates actually, there's been a very cool line of work in the last maybe five to seven years or so in distributed computing around accountability, which is when something goes wrong, can you tell if it went wrong and who might be responsible for it? And so in particular, like if you want to think about Byzantine fault tolerance systems and say, well, what would happen if actually you did have too many malicious actors, right? What could happen? And you could have a consistency violation. But accountability says the only way to create a consistency violation is by signing lots of inconsistent things and then through inspection, you can actually identify bad actors who double signed on different conflicting states. I could imagine this being developed maybe 20 years ago, but it's mostly been developed in the last five to seven years. So analyzing PBFT style protocols, not just in the regime where the number of faulty nodes is small, but also where it's actually bigger than the threshold.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Yeah, I wanted to add that sometimes good systems work that have benchmarks that show good practical results. They change people's mind. They say, oh, this technology can actually be used. There's a difference between having a theoretical paper saying it's possible and seeing good benchmarks.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“This I mean, we were just, you know, picking up stuff from theoretical computer science and using it as we needed it. You may be right that it was thought of as this work is interesting, but who cares The theoretical work. And now you could see how it really fit right into a practical system. You were happy that there were techniques that people had developed that served our needs. Still, you can see the bridge between theory and practice. If we hadn't been around the theory, then, you know, we would have been really stymied in what we were doing”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“That's right. Correct me if I'm wrong, but PBFT to me felt like the bridge from that theoretical work to practical systems, right? I mean, my sense just, you know, from reading the PBFT paper and all the reactions around it was perhaps there was this aha moment. It's like, oh, wait a minute, this isn't just to prove the theorems. Like we can actually sort of build a system where this is really how it's going to work. Was that what happened?”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Protocol. But, you know, it's easier in hindsight to see it than it was at the time. It took quite a bit of thinking to come out with it. But that was still, it was the underpinning of how we came up with PBF2.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“The way you handle the problem is you never trust an individual replica, you only trust the group. And the group has to consist of a sufficient number of replicas to be able to prove that this is what really happened. And of course, we need a way that this proof can be offered at a later point in time. And for that, we use certificates. So a certificate consisted of 2F plus 1 signed messages all stating the same thing, and that would be a proof that you got to a particular point in the protocol. And the extra step happened because the primary could only suggest the next step. Then 2F plus 1 replicas together have to produce a protocol that says we're doing this next and putting this next in the ledger. And then you have to do another phase to actually commit that step. And that's how you get this.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“About malicious attack on the content of messages. For that, of course, we immediately started using cryptography because that was the way to make sure that messages can get from here to there and you knew who they were coming from and you knew whether they were correct or not. The bigger problem that we were dealing with was the replicas that lie. And of course, that's why you need three F plus one replicas instead of 2F plus 1. And the biggest problem you have there is that the primary might lie. Felt to me like we were in a fun house full of these distorting mirrors, and you had to really think about things in an odd way to come to grips with this. But in the end, the solution was a protocol that was strongly based on VSTAM replication. It had one more phase in the replication protocol because”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“DARPA was a very important between DARPA and NSF. I mean, they were the reasons that research was getting funded all those years. They are one of the very important backbone. And then what we did was we simply started from viewstamp replication. My group all knew what viewstamp replication was. And I don't think it was understood at other places. And so we had that stepping stone that other people didn't have. And we used it. It just seemed like it was a natural thing to do. We had this algorithm that worked for benign failures. Okay, let's add Byzantine failures and see what happens. And we also knew from the theoretical work that we were going to need three F plus one replicas instead of 2F plus 1. But again, we're looking for a practical protocol that people will really use in practice. So we started from Geostap replication, but it's a very different problem once you add those Byzantine failures because you have to be prepared for replicas that lie. And of course, you also have to worry.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, the way TBFT came about, practical Byzantine fault tolerance is I had a student Miguel Castro who was looking for a PhD thesis and I suggested to Miguel that he look at the RFPs that DARPA had put out and see if anything interested him. And he found an RFP that was looking for ways to handle the malicious attacks that were going on on the internet. And so he came to me and he said, why don't we see whether we can figure out a way to do replication that handles these malicious attacks? And that seemed like a great idea. I mean, I'm not saying it wouldn't have happened anyway, but the fact that DARPA had recognized that this was a serious problem, the problem of malicious attacks and was looking for research in that area certainly was something that caused this work to happen in my group at that time. And I think that”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“The story I heard was, well, in the 90s, the Google file system paper was published. And that paper used replication and talked about using Paxos. And I was kind of peeved because one of my students was working there and I thought he could have talked about view stamp replication. But the story I heard was that Bill Weil, who had been a student of mine in the 80s, happened to be at Google and he was looking at what was going on in the Google file system. And he said, oh, he said, that's view stamp replication And they really were the same protocol developed in two different places. It was just funny how we kind of couldn't see that for that period”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“We finished Few Stamp Replication. We published it at sometime in the late 80s That was when I came up with what came to be called the Liskoff substitution principle. But we had put that aside. Of course, it was early days. It was not in any commercial environment yet. And also, you know, Leslie Lamport was working on Paxos. And I actually heard him give a talk in the 80s about Paxos, and I didn't understand what he was talking about. And I had certainly no idea it was the same thing. But this was a mutual lack of understanding.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, I can't answer that question, but I really think we have many strong places. And I think all the top institutions could have done this work. But MIT is a wonderful place. And we also took teaching very seriously. And I do think teaching a researcher very closely connected because when you teach well, you teach from first principles. And when you do good research, you have to truly understand. So you're really doing research from first principles. And it's also very important in research to understand what you don't understand. I always tell my students that. There's where you get the insight into where you have to move. And you don't want to have an incomplete understanding of why something works. You know, you have to really understand it completely. And we always tried to prove the correctness of these as we got.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“And I was going to ask about that actually, which was how important was the mil u of MIT for the work that you did? Do you think if you'd been in another strong department, things would have played it out in a similar way? Or is the MIT imprint very strong in some way?”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Well, I don't know that I can talk about the practical side and how it influences theory. But in my group, I always told my graduate students they should take theory courses, you know, theoretical computer science is the backbone of our field. We always wanted to track what was going on in there. The main thing that was impacting my work was always understanding what they were doing and also things like cryptography and so forth, which came to be so important, not in those days so much, but in later work. And of course, I was fortunate to be at a place where Ron Revest was and his colleagues, you know, and so forth.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“These were failures where machines were either running or they were completely silent. And messages might arrive, they might not arrive at all, or they might arrive corrupted, but if they were corrupted, you could tell. So we didn't worry about Byzantine failures. We only worried about the simple failures, which were, in fact, the main failures that happened at that time because it was just the days of the ARPANET and we were all friends. And we didn't have the malicious attacks that showed up in the 90s once we had an internet.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Primary failed. And so, in that sense, we were building a ledger. We didn't use that terminology. We thought of this more like a log because that's what we used to call it in the systems community when we were talking about a single machine where you were always writing stuff to the log so that if the machine failed, you could come back up again and pick up where you left off. So now it was a log based in a distributed system. And we were really thinking in terms of a file system, but the protocol didn't have anything to do with the application. We were really building a ledger and doing so in a way that guaranteed that the history going forward was always preserved. But a very important point is we only thought about”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Crashing halt. And there was even some concern about whether he could get it going again in the right way. And so we had to figure out how to solve that problem. And that was the contribution of USTAP replication. We came up with a protocol that it had what we called the primary. And the primary was telling the backups what to do. And we were carrying out a protocol that was similar to two-phase commit to make this happen. But if the primary seemed to not be doing its job, the backups then carried out another protocol where they moved to what we called a new view in which a different replica became the primary. And of course, this had to happen in a way that guaranteed that everything that had reached the commit point in the previous view made it into the new view with the history was exactly the same as what it had been before the prime.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“To think of having a group of replicas that were in charge of things, although I didn't have that insight at the time, it just seemed like this looked like a good approach. So Brian and I dug into it. And there was work in theoretical computer science. I mean, they understood then that you needed two F plus one replicas to survive F failures. And there may even have been a protocol, but our focus was different because we were always interested in practical protocols that you could really use that were efficient. And we based our work on two-phase commit. But of course, two-phase commit didn't actually solve the problem because two-phase commit had what was in it called the embarrassing pause or the window of vulnerability, where if the primary failed, the primary that was running the protocol, the whole thing came to a close.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“It just seemed like a really interesting problem. I always like to work on stuff that looks important, so it was clearly something that was coming, and it was clearly something we needed, and we really didn't understand how to implement a system like that. The view in the systems community at that point was mainly to think about this using locking. So the idea was you had the users, and they would lock the replicas so that they could have control. So that way you were going to make sure that you didn't have concurrency problems. And to me, that seemed like a very bad solution because that means you have to depend on these other users at far-flung sites to do their job. And they might not do it. So I thought, let's switch the work to the replicas. And I think in retrospect, this is because of the work I did in Argus, where I was already using atomic transactions, and it was already sort of natural.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“So, to bring it back to kind of your research, so entering distributed systems, working on Argus, beginning of the 80s. And then at some point, you decided to focus specifically on replication. And Itai mentioned the view stamp replication protocol. So could you talk a bit about what led you to focus on that problem at that time?”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“And so I got interested in it. And I had a student, Brian Oakie, who was looking for a thesis topic. And so the idea of a replicated file system seemed like a really interesting thesis topic. This is in the mid-80s.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“You know, I don't think it had anything to do with object oriented. I think it was a question that was of great interest in the systems community at that time. We could all see that it would be really nice to have a file system that was implemented at many replicas and where lots of people could be using the same files. In those days, if you wanted to write a paper or do other work with somebody else, you had to use file transfer. And you couldn't access their file system. What you could do is communicate by email in a sort of not terribly attractive way. And of course, you have the problem that if your computer was down, you had no access to your files. And wouldn't it be nice if we could have a replicated system where the stuff was always there and so forth? So this was a problem that was sitting there in the systems area that people were interested in.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“So your early work on distribute computing view stamp replication, you were kind of trying to merge this object-oriented approach with handling failures. So I wonder what was kind of the main motivation for thinking about handling failures in a distributed system.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Instead, you have to have lemmas and the lemmas each have a statement of what they are, and then you prove their correctness independently, and you can reason about each piece of the theorem as a separate unit. And this is exactly what's going on in a modular program. You know, you have each module. It's got a specification. You can do a proof of the correctness of the code that implements the module without having to look at any other module's code. You just look at the specifications of other modules. And that's very similar to a theorem with limmas and so forth. And I just think looking back that since I was a math major in college, it was just a very natural way of thinking about things to me, even if I hadn't had it in the front of my mind what I was working on, the original work on modularity.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“I would say that modularity is everything in building large programs. And it was only many years later that I started to think of modularity and theorems as being similar. But it seems very clear that they are because in a theorem, you start off with the statement of what is supposed to be true. You want to reason about this. But of course, you don't do it as one big blob, which by the way was kind of how programs were written back in the 60s.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“We picked up transactions from database systems and we ran those computations as atomic transactions. And we had a two-phase commit protocol going on. It seemed like a continuation in a more evolved or complicated environment, so which allowed me to look at additional problems.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“Clue, which was parallel computing. I had decided in clue that that was going to be a sequential language because I felt we had enough stuff going on that I didn't want to complicate it by adding concurrency as well. And so now I was able to pick up concurrency, but in this more interesting world where concurrency wasn't just that you had a for loop where you ran a bunch of threads in parallel, but instead you had multiple users and they might be making requests in parallel and stuff like that. And one of the interesting things about Argus was that we had to worry not just about concurrency, but also failures. And we had computations there that would visit several nodes of the network. And then at the end, we had to make sure that such a computation either happened completely or had no impact whatsoever. And so, of course.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“I may have thought of it as a pivot, but my first project there was a programming language. And that programming language was really an extension of the language I'd already developed. We had this language called Clue, which supported abstract data types and objects. And in Argus, which was the new language, we had abstract data types, and then we had one additional feature, this new kind of object, which we called a guardian. And the idea with a guardian was it resided at one node of a network. It provided operations that could be called from other nodes. And so the idea was a distributed program consisted of all these guardians, each running on its node, communicating with each other. And so really, it wasn't that much of a pivot at all. It was, in fact, picking up something I'd had to leave behind.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“So, what happened was I had finished working on Clue, which was the programming language that I developed with my group to provide access to data abstraction as a way of building programs. And I had thought a little bit about maybe starting a company to market the language, but I realized that I was much more interested in research. And I also thought that I had sort of done as much programming language research as I had anything interesting to do at that point. And I started looking around and I read a paper by Bob Kahn in which he talked about the dream of distributed computing and how there would be distributed programs that had components at different nodes in a network and communicated over the network. And only nobody knew how to build them. And so I thought there's a great problem. I jumped into distributed computing.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source
“DARPA had recognized that this was a serious problem, the problem of malicious attacks, and was looking for research in that area. I had a student Miguel Castro, who came to me and he said, why don't we see whether we can figure out a way to do replication that handles these malicious attacks? And that seemed like a great idea. The problem, if the primary failed, the primary that was running the protocol, the whole thing came to a crashing halt. We came up with a protocol that if the primary seemed to not be doing its job, the backups then carried out another protocol in which a different replica became the primary. We thought that at some point people would start to use this and then along came blockchains. Well, that was very shocking.”
2026-07-13 · a16z Podcast · Before Blockchains, There Was State Machine Replication · IDENTIFIED FROM THE TRANSCRIPT · source