← The a16z Show
The a16z Show
Before Blockchains, There Was State Machine Replication
00:37:20
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.
Loading summary
Transcript64 lines
- [00:01]
Barbara Liskov
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 and. Well, that was very funny.
- [00:46]
Tim Roughgarden
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?
- [00:54]
Barbara Liskov
Computer science is in a very strange place right now with the advent of AI. I think that as far as research is concerned.
- [01:02]
Podcast Narrator
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 Roughgarten and Atai Abraham speak with Turing Award winner Barbara Liskoff, 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 this 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.
- [01:50]
Tim Roughgarden
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 a 16z 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 Liskoff. 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 stamped replication from the 1980s to practical Byzantine fault tolerance, or PBFT. A decade later, a 16Z crypto research partner Itay Abraham joins me as we talk with Dr. Liskoff 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 Liskoff, thanks so much for joining us for the conversation today. Really appreciate you taking the time.
- [03:02]
Barbara Liskov
Sure.
- [03:03]
Tim Roughgarden
I thought maybe it would be fun to start to just discuss a little bit about how you got into distributed systems research, which my understanding was maybe around 1980 or so, especially given that 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?
- [03:25]
Barbara Liskov
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. So I jumped into distributed computing.
- [04:29]
Tim Roughgarden
Wow. Fantastic.
- [04:30]
Barbara Liskov
And it was a great move.
- [04:32]
Tim Roughgarden
Wow. It was great for computer science that that happened. No doubt about 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, how much did sort of the mindset and the approach to abstraction that you developed early in 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?
- [04:54]
Barbara Liskov
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, 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 CLU 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 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 environments, which allowed me to look at additional problems.
- [07:03]
Tim Roughgarden
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, 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 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.
- [07:30]
Barbara Liskov
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 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. 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 limits 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. I was working on the original work on modularity.
- [08:51]
Itay Abraham
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?
- [09:07]
Barbara Liskov
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 a not terribly attractive way. And of course you had 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. 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. This is in the mid-80s, so this
- [10:18]
Tim Roughgarden
is maybe a little bit of a, 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 2,000 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, dawn network, multiple and operating systems. And 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:00]
Barbara Liskov
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, Lampson 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, which is a site in Monterey. But the conference was small 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:40]
Tim Roughgarden
Sounds like a magical time. Sounds amazing.
- [11:42]
Barbara Liskov
It was a good time.
- [11:43]
Tim Roughgarden
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. Right. And you know, Itay mentioned the View Stamp replication protocol. So could you talk a bit about what led you to focus on that problem? At that time it just seemed like
- [12:03]
Barbara Liskov
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. 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 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 2F +1 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 commitments. 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 he'd 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 ustamp 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 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. And 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. 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 army and we were all friends and we didn't have the malicious attacks that showed up in the 90s once we had an Internet.
- [16:07]
Itay Abraham
I think this was like a really great description of view stamp replication. And so in some sense, like this whole idea of moving from one view with one primary to a new view with the new primary gave this birth to these view change protocols, which I think are now everybody's using them, but it's quite amazing to see that Basically, they come from the early 80s in a way. Right.
- [16:29]
Tim Roughgarden
And this is maybe another little bit of a digression, but Professor Liskoff, you mentioned that there was sort of in the background there had been some work 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'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 how you see the flow of influence. Like, in what ways has kind of the work on the theoretical side informed your work or other work on the practical side and vice versa?
- [17:03]
Barbara Liskov
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. 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 Rivest was and his colleagues and so forth.
- [17:45]
Tim Roughgarden
And I was gonna ask about that, actually, which was, how important was the milieu 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?
- [17:59]
Barbara Liskov
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 and 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 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:00]
Tim Roughgarden
I'm glad to hear you say that. 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. And research is the special case where k equals 0. Or for the first time, people are understanding it sort of deeply.
- [19:19]
Barbara Liskov
That's a good way of looking at it.
- [19:21]
Tim Roughgarden
So I view them. I completely agree with you. Very synergistic activities. And that's kind of the twin pillars of the professor's role, I think, really. So returning to the research side. So Vue Stamp replication came out in the late 80s, and then there was sort of a period where I think the focus of your group turned away from replication to some extent, still partly in distributed systems.
- [19:44]
Barbara Liskov
We finished Vue Stamp replication. We published it at some sometime in the late 80s. That was when I came up with what came to be called the Liskov Substitution Principle. But we had put that aside. Of course, it was early days. It was not in any commercial environment yet. And also, 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. The story I heard was, well, in the late. 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 V 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.
- [21:01]
Tim Roughgarden
Fascinating. It's interesting how 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:13]
Barbara Liskov
and the same idea does get discovered more than once. Yes.
- [21:16]
Tim Roughgarden
Yeah. So that seems like a great, great example of that. But then you did get, in the late 90s, you did get pulled back into replication, right, in the famous pbft, Practical Byzantine Fault Tolerance Protocol. And my understanding is that was at least in part inspired by a DARPA baa, you know, a sort of request for proposals. So we'd 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:54]
Barbara Liskov
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 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 V stamp 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 two F plus one. But again, we're looking for a practical protocol that people will really use in practice. So we started from V stamp 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 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 3F +1 replicas instead of 2F +1. 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 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 used certificates. So a certificate consisted 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 2F 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 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:08]
Tim Roughgarden
Yeah, and just for the audience whose benefit, I mean, this idea of sort of certificates of 2F plus one signatures, I mean, this has been a very, very influential idea in many of today's major blockchain protocols. Indeed, this is how they prove the ordering of their transactions to others.
- [26:25]
Barbara Liskov
But of course, we didn't invent certificates. They were coming out of theoretical work.
- [26:29]
Tim Roughgarden
That's right. Correct me if I'm wrong, but PBFT to me felt like the bridge from that theoretical work to practical systems. I mean, my sense, just from reading the 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. We can actually sort of a system where this is really how it's going to work. Was that what happened?
- [26:51]
Barbara Liskov
I mean, we were Just 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 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. Still you can see the bridge between theory and practice. If we hadn't been around the theory, then we would have been really stymied in what we were doing.
- [27:24]
Itay Abraham
Yeah, I wanted to add that sometimes good systems work that have benchmarks that show good actual 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.
- [27:40]
Barbara Liskov
I see what you're saying, saying that file system works well, 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:55]
Tim Roughgarden
Speaking of 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, 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, 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.
- [28:49]
Barbara Liskov
You know, I'm not aware of that work, but it does sound interesting.
- [28:52]
Tim Roughgarden
Yeah, it's very cool.
- [28:53]
Itay Abraham
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 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:28]
Barbara Liskov
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 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.
- [30:19]
Tim Roughgarden
It's another variant of the modularity principle that you were proposing earlier, perhaps, or some of the abstraction.
- [30:24]
Barbara Liskov
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, 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:54]
Itay Abraham
Yeah, I guess today it's a very common understanding, right? This separation of different layers of, 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
- [31:08]
Tim Roughgarden
and 90s and then even more so. I mean, I would say Turing complete blockchain protocols 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. So these blockchain protocols are in some sense one of the more literal embodiments, I think, of the general state machine replication problem that we've seen to date, which is super interesting.
- [31:46]
Barbara Liskov
I mean, 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.
- [32:11]
Tim Roughgarden
There was A long period of time. I mean, so blockchains were sort of launched with the 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 it's someone who loves computer science, loves research, 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, how to get started?
- [33:12]
Barbara Liskov
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. 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 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 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 starting in the late 70s with John Guttag, 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, you know.
- [35:20]
Tim Roughgarden
Yeah, is it a semicolon or a comma or. Yeah, exactly.
- [35:24]
Barbara Liskov
So 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'm saying there's great research to be done and a lot of it's in the systems area.
- [36:00]
Tim Roughgarden
I couldn't agree more.
- [36:01]
Itay Abraham
I think that's a great, beautiful note
- [36:04]
Tim Roughgarden
to close on, I think.
- [36:05]
Barbara Liskov
Okay, good. I'm glad to hear it. Anyway, so, I mean, this has been fun.
- [36:09]
Tim Roughgarden
It's been an honor to have you. Professor Liscot, thanks so much for. Thanks so much for taking the time.
- [36:13]
Barbara Liskov
You're welcome and nice to meet you.
- [36:14]
Itay Abraham
Thank you very much.
- [36:15]
Tim Roughgarden
Take care.
- [36:18]
Podcast Narrator
Thanks for listening to this episode of the A16Z podcast. If you like 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 X16Z and subscribe to our substack@a16z.substack.com thanks again for listening and I'll see you in the next episode. 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 invest 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.