Before Blockchains, There Was State Machine Replication

Every blockchain today relies on replication techniques first developed in the 1980s by researchers who weren't thinking about cryptocurrencies at all. In this episode, Tim Roughgarden speaks with MIT professor and Turing Award winner Barbara Liskov, one of the pioneers of programming languages, fault tolerance, and distributed systems. Joined by a16z crypto research partner Ittai Abraham, they trace the evolution of ideas that now underpin modern blockchain networks. The conversation explores viewstamped replication, Practical Byzantine Fault Tolerance (PBFT), state machine replication, and why concepts developed decades before Bitcoin became the foundation for today's blockchain protocols. Along the way, Liskov reflects on the relationship between theory and practice, the importance of modularity and formal reasoning, and why AI is creating a new generation of systems research.

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  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. 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. 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.

• 0:44Speaker 00

  Well, that was very funny.

• 0:45Speaker 01

  Someone who loves computer science, loves research, wants to do important work, wants to have an impact. What would you suggest as kind of a mindset, as an approach?

• 0:54Speaker 00

  Computer science is in a very strange place right now with the advent of AI. I think that as far as research is concerned...

• 1:02Erik Torenberg?

  As part of our summer feed drop series, we're sharing another episode from the A16Z Crypto Show. Every blockchain today relies on replication techniques first developed in the 1980s, years before anyone imagined cryptocurrencies. In this episode, Tim Roughgarden and Atai Abraham, speak with Turing Award winner Barbara Liskov, whose pioneering work on distributed systems, state machine replication, and practical Byzantine fault tolerance laid the foundation for many of today's blockchain protocols. Whether you're new to crypto or already building in the space, this conversation offers a deeper understanding of the computer science behind modern blockchains. If you enjoy this episode, be sure to follow the A16Z Crypto Show for more conversations like this.

• 1:50Speaker 01

  Hi, everyone, and welcome to First Principles, a series by the team at A16Z Crypto. I'm Tim Roughgarden. I'm the head of research at A16Z Crypto. And today, we're exploring a core challenge in distributed computing. How can a system remain reliable when some of its parts fail or behave maliciously? In this episode, we're going to speak with the Turing Award-winning computer scientist whose work helped answer this question, Dr. Barbara Liskov. She's famous for many things, but today, we're going to focus on her work that laid the foundations for modern blockchain systems. For example, from view standard replication from the 1980s to practical Byzantine fault tolerance, or PBFT, a decade later. A16Z Crypto research partner,

• 2:35Speaker 01

  Atai Abraham, joins me as we talk with Dr. Liskov about her path from programming languages to distributed systems, the evolution of practical replication protocols, the state machine replication paradigm underlying blockchains, and how emerging technologies like AI are reshaping systems research. Here's our conversation. Professor Liskov, thanks so much for joining us for the conversation today. I really appreciate you taking the time.

• 3:02Speaker 00

  Sure.

• 3:02Speaker 01

  I thought maybe it would be fun to start to just discuss a little bit about how you got into distributed systems research, which, from my understanding, was maybe around 1980 or so, especially given that, you know, throughout the 1970s, you did a lot of extremely important work on other topics: operating systems, programming languages, data abstraction. So why this sort of segue into distributed systems around that time?

• 3:24Speaker 00

  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

• 4:09Speaker 00

  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. So I jumped into distributed computing.

• 4:28Speaker 01

  Wow, fantastic.

• 4:29Speaker 00

  And it was a great, yeah, great move.

• 4:32Speaker 01

  Well, it was great for computer science that that happened, no doubt about it. I'm curious, did it feel like a pivot at the time? Like you were really changing your research field? And maybe a related question would be, you know, how much did sort of the mindset and the approach to abstraction that you developed during your career, how much did that port over? Versus how much did you need to really have a new sort of toolbox for working on those problems?

• 4:53Speaker 00

  Well, 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 the 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,

• 5:38Speaker 00

  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 for 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

• 6:22Speaker 00

  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, 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.

• 7:03Speaker 01

  Yeah, I was just on a personal note. It was very cool for me to sort of read all that backstory because when I'm explaining blockchain execution to sort of undergrads in my class, you know, I had taken to using object-oriented programming as kind of the mental model they could kind of fit it into as far as the sort of interoperability between different parts of the state. And so then, you know, to see that indeed, that's exactly sort of the roots of sort of your thinking about it in those early systems, I thought was really, really cool to see.

• 7:28Speaker 00

  Yeah. 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 a 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 and 70s. 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.

• 8:12Speaker 00

  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 lemmas 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.

• 8:51Speaker 03

  So your early work on distributed 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?

• 9:06Speaker 00

  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, you know, 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 know, you couldn't access their file system. What you could do is communicate by email in a sort of a, you know, not terribly attractive way. And of course, you had the problem that if your computer was down, you had no access to your files.

• 9:51Speaker 00

  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. And so I got interested in it. And I had a student, Brian Okey, who was looking for a thesis topic. And so the idea of a replicated file system seemed like a really interesting thesis topic. And this is in the mid 80s.

• 10:17Speaker 01

  So this is maybe a little bit of a digression, but I'm just curious, which is a little bit about what systems research was like at that time as a community. So my career started kind of around 2000 or so. And for much of my career, the field of systems is so large, it feels a little bit fragmented to me. Like you've got conferences devoted to databases, multiple, multiple Don network, multiple in operating systems. Meanwhile, you've already talked about the idea that it was obvious throughout the systems community, as if it was one community. You also talked about how just, you know, the proximity of the different areas meant that, you know, two-phase commit protocols and transactions and atomicity, you recognize that immediately as things you were going to need in the distributed systems context. So what were things like back then?

• 11:00Speaker 00

  They were very nice. So it used to be SOSP was the main conference. And I remember going to SOSP and the people you think of in the systems area like Butler Lamson and so forth were there, but so was Jim Gray, so was Bruce Lindsey. Well, the top database people were all there. And the conference was small enough that we used to have it at Asilomar.

• 11:23Speaker 01

  Wow.

• 11:24Speaker 00

  Which is

• 11:25Speaker 01

  In Monterey.

• 11:26Speaker 00

  Side in Monterey.

• 11:27Speaker 01

  Yeah.

• 11:28Speaker 00

  But the conference was small. Uh, in those days, there may have been other specialized conferences, but mostly we were together and so it was easy for us to, to see the sort of field as a whole.

• 11:39Speaker 01

  Sounds like a magical time. Sounds amazing.

• 11:42Speaker 00

  It was a good time.

• 11:43Speaker 01

  So to bring it back to kind of, um, your research, so, so entering distributed systems, working on Argus, beginning of the eighties. And then at some point you decided to focus specifically on replication, right? And, you know, your time mentioned the view stamp replication protocol. So, so, uh, could you talk a bit about what led you to focus on that problem at that time?

• 12:02Speaker 00

  It just seemed like a really interesting problem. I always liked 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.

• 12:43Speaker 00

  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 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, uh, 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.

• 13:28Speaker 00

  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 crashing halt. And there was even some concern about whether you 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 U stamp replication. We came up with a protocol that it had what we called the primary and the primary was

• 14:11Speaker 00

  telling the backups what to do. And we were carrying out a protocol that was similar to two-phase commit to have, 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 primary failed. And so in that sense, we were building a ledger. We didn't use that terminology.

• 14:53Speaker 00

  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 what we referred to as benign failures.

• 15:33Speaker 00

  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 nineties once we had an internet.

• 16:06Speaker 03

  I think this was like a really great description of, of view stamp replication. And, and so in some sense, like this whole idea of, of moving from one view with one primary to a new view with a new primary gave this birth to these view change protocols, which I think are

• 16:21Speaker 00

  Yeah.

• 16:22Speaker 03

  Now everybody's using them, but it's, it's, it's quite amazing to see that, you know, basically they, they come from the early eighties in a way, right?

• 16:28Speaker 01

  And this is maybe another little bit of a digression, but Professor Liskoff, you mentioned, um, that there was sort of in the background, there had been some work on the, on the theory side, you know, just identifying what is the in principle kind of, you know, best possible fault tolerance one could perhaps achieve. And so I, I'd love to just to hear your thoughts on kind of theory versus practice, theory versus systems, you know, maybe both at that time and how it's evolved over the years and, and how you see the, the flow of influence, like in what ways this kind of the work on the theoretical side informed your work or other work on the practical side and, and vice versa?

• 17:02Speaker 00

  Well, I don't know that I should talk about the practical side and how it influences theory, but, um, in my group, I always told my, I always told my graduate students they should take theory courses. You know, theoretical computer science is, 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, you know, understanding what they were doing and also of things like cryptography and so forth, which came to be so important in, not in those days so much, but in later work. And of course I was fortunate to be at a place where Ron Rovest was and his colleagues, you know, and so forth.

• 17:44Speaker 01

  And I was going to ask about that actually, which was how, how important was the milieu of MIT for the, 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?

• 17:58Speaker 00

  Well, I, I, I can't answer that question, but I really think, you know, we have many strong places and I think all the top institutions could have done this work. But, uh, MIT is a wonderful place and we also took teaching very seriously. And I do think teaching or research are 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

• 18:42Speaker 00

  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 to these more complicated protocols, you really, you have to reason about them carefully to make sure they really work.

• 19:00Speaker 01

  I'm glad to hear you say that. I, I couldn't agree more. You know, what you're talking about teaching and research, I sometimes describe teaching as increasing the number of people who understand something from a smaller number K to a bigger number N.

• 19:11Speaker 00

  Yeah.

• 19:12Speaker 01

  And research is the special case where K equals zero, or for the first time people are understanding it sort of deeply.

• 19:17Speaker 00

  That's a good way of looking at it.

• 19:20Speaker 01

  So I view them, I completely agree with you, very synergistic activities and, and you know, that's kind of the twin pillars of the, the professor's role, I think really.

• 19:28Speaker 00

  Yeah.

• 19:29Speaker 01

  So returning to the, to the research side, so view stamp replication came out in the late eighties. Uh, and then there was sort of a period where I think the, the focus of your group turned away from replication to some extent, still partly distributed systems.

• 19:43Speaker 00

  We finished view stamp replication. We published it at some time in the late eighties. 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, uh, environment yet. And also, you know, Leslie Lampert was working on Paxos and I actually heard him give a talk in the eighties 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.

• 20:17Speaker 01

  Yeah.

• 20:18Speaker 00

  The story I heard was, well, in the late, in the nineties, 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 eighties, 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.

• 21:00Speaker 01

  Fascinating. It's interesting how there, there's sometimes just moments in time where it feels like the right time for certain work to be done. And often it happens, it's sort of multiple different sort of groups do it at the same time.

• 21:12Speaker 00

  Places and the same idea does get discovered, discovered more than once. Yes.

• 21:17Speaker 01

  Yeah. So that seems like a great, great example of that. But then you did get in the late nineties, you did get pulled back into replication, right? And the famous PBFT, practical Byzantine fault tolerance, um, protocol. And my understanding is that was at least in part inspired by DARPA, BAA, you know, a sort of request for proposals. So would love to hear a little bit about that story and then maybe relatedly just perhaps the importance of collaboration outside of academia, whether it's with, you know, kind of government funding agencies or industry and how maybe that's If that's been important in your work, how that's been important?

• 21:54Speaker 00

  Well, the way PBFT 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

• 22:35Speaker 00

  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 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 backbones of why we have the Internet that we have today. Without that research funding, it would have been much more difficult to have done all that work. So that's how we got started on Byzantine Fault Tolerance. And then what we did was we simply started from view stamp replication. My group all knew what view stamp replication

• 23:20Speaker 00

  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 two F plus one. But again, we're looking for a practical protocol that people will really use and practice. So we started from view stamp replication, but it's a very different problem once you add

• 23:59Speaker 00

  those Byzantine failures, because you have to be prepared for replicas that lie. And of course, you also have to worry 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 two F plus one. And the biggest problem you have there is that the primary might lie. It felt to me like we were in a funhouse full of these distorting mirrors,

• 24:41Speaker 00

  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 view stamp replication. It had one more phase in the replication protocol, because 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

• 25:24Speaker 00

  of two F plus one, 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 two F plus one 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 this 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 PBFT.

• 26:07Speaker 01

  Yeah, and just for our audience's benefit, I mean, this idea of sort of certificates of two F plus one signatures, I mean, this has been a very, very influential idea. And many of today's major blockchain protocols, indeed, this is, this is how they prove, you know, the ordering of their transactions to others.

• 26:24Speaker 00

  But of course, we didn't invent certificates. They were coming out of theoretical work.

• 26:28Speaker 01

  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 a PBFT paper and all of 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? Or?

• 26:50Speaker 00

  I mean, we were just, you know, picking up stuff from theoretical computer science and using it as we needed it. But you may be right, that it was thought of as this work is interesting, but, you know, who cares? The theoretical work. And now you could see how it really fit right into a practical system. We 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 aware of the theory, then, you know, we would have been really stymied in what we were doing.

• 27:24Speaker 03

  Yeah, I wanted to add that sometimes, you know, good systems work that have benchmarks that show, you know, good actual practical results, they change people's mind. They say, oh, this this technology can actually be used. There's a difference between having a theoretical paper saying it's possible and seeing, you know, good benchmarks.

• 27:40Speaker 00

  I see what you're saying.

• 27:40Speaker 03

  Saying that, you know, file system works well.

• 27:43Speaker 00

  I was never worried about that. But of course, I was just the one who wanted to find the stuff that would make the system work. And it was hard, but it was a lot of fun.

• 27:55Speaker 01

  Speaking of certificates, actually, there's been a very cool line of work in the last maybe five to seven years or so, 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 Tolerant 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.

• 28:39Speaker 01

  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 than the threshold. So.

• 28:49Speaker 00

  You know, I'm not aware of that work, but it does sound interesting.

• 28:52Speaker 01

  Yeah, it's very cool.

• 28:53Speaker 03

  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 two F plus one 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?

• 29:28Speaker 00

  Well, I think that's, 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 wrote into the ledger, you know, 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

• 30:13Speaker 00

  application. You wanted to find this generic thing that would work for many applications.

• 30:19Speaker 01

  It's another, very another modularity principle that you were proposing earlier, perhaps, or to the abstraction.

• 30:24Speaker 00

  I think it was just sort of, in a way, obvious that you wanted, you know, you mentioned state machine replication in the in the email you sent me, and we knew we were working on state machine replication. And state machine replication has the idea that whatever it is that you're doing, that's just the thing, you know, and you instead just think about the order, and this is operation number 25, or something like that. So I think it was very fundamental, even in view stamp replication, to what we were doing.

• 30:54Speaker 03

  Yeah, I guess today is a very common understanding, right? This this separation of different layers of consensus and execution. And it's, yeah, it's really cool to see that these are kind of ideas that, again, evolved from from these these work from the 80s and 90s. Yeah.

• 31:08Speaker 01

  And then even more so, I mean, I would say, Turing complete blockchain protocols, like, you know, Ethereum, Solana, et cetera, they're they're almost like literal implementations of the fully general state machine replication problem, right? 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, you know, in some sense, a special case, a special instance run in the general sort of SMR protocol. So these blockchain protocols are in some sense, you know, one of the more literal embodiments, I think, of the general state machine replication problem that we've seen today. Just super interesting. So.

• 31:46Speaker 00

  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.

• 32:09Speaker 00

  Well, that was very funny.

• 32:10Speaker 01

  There was a long period of time. I mean, so right. 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, you know, 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, you have advice for the

• 32:54Speaker 01

  younger generation. So it's someone who loves computer science, loves research, you know, maybe distributed systems, maybe more broadly, thinking about computer science, you know, wants to do important work, wants to have an impact. What would you suggest as kind of a mindset, as an approach, how to get started?

• 33:12Speaker 00

  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, as a field for young, 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.

• 33:57Speaker 00

  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. 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

• 34:40Speaker 00

  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, that's a good job. The course that I developed at MIT in the 19, starting in the late 70s with John Guttig, which was a course about how do you build big programs? And 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?

• 35:19Speaker 01

  Yeah. Is it a semicolon or a comma? Yeah, exactly.

• 35:23Speaker 00

  So I, I still think computer science is a great field, and I think there's a lot to be done. And the, 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 be taught, and a lot of it's in the systems area.

• 36:00Speaker 01

  I couldn't agree more. I think that's a, that's a great, great note. Beautiful note to close on, I think.

• 36:05Speaker 00

  Okay, good. I'm glad to hear it. Anyway, so, I mean, this has been fun.

• 36:09Speaker 01

  It's been an honor to have you, Professor Liskov. Thanks so much for, thanks so much for taking the time.

• 36:13Speaker 00

  You're welcome. And nice to talk to you both.

• 36:15Speaker 01

  Take care.

• 36:18Erik Torenberg?

  Thanks for listening to this episode of the A16Z Podcast. If you liked this episode, be sure to like, comment, subscribe, leave us a rating or review, and share it with your friends and family. For more episodes, go to YouTube, Apple Podcasts, and Spotify. Follow us on X at A16Z and subscribe to our Substack at a16z.substack.com. Thanks again for listening, and I'll see you in the next episode.

• 36:43Erik Torenberg?

  As a reminder, the content here is for informational purposes only, should not be taken as legal, business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund. Please note that A16Z and its affiliates may also maintain investments in the companies discussed in this podcast. For more details, including a link to our investments, please see a16z.com/disclosures.