 We're on to our first speaker, Juan Benets. While I don't think Juan needs an introduction in this context is the inventor of the interplanetary file system, IPFS, and the Filecoin. And he is, of course, the founder of Protocol Labs. He studied computer science, sorry, at Stanford. And he's obsessed with knowledge, science, and technology. So take it away, Juan. Thanks so much for the intro, George. So hey, it's an honor to be here with you. Two years after the first consensus day, where we had a very small event, a well-backed, and a huge thank you to the organizers for creating the next iteration of this event. I wanted to have one small note here that that day, two years ago, we formalized the SSLE Open problem and we published an RFP. And that's probably the biggest success of that conference, which is that now, two years later, many published solutions exist, which is pretty sweet. And when I was looking at the agenda for this consensus day, it's really cool to see so many sessions that directly address a bunch of the things that we were talking about as potential things that would be interesting directions and consensus in the future. So I had a few here that just directly touched on stuff. So yeah, it's been so awesome to see all of the amazing work that got presented yesterday, and super excited for all the amazing stuff coming here today. So, and I can't wait, of course, for consensus day 22 next year. So looking forward to an even greater event then. And thank you very much for all the organizers for putting all of this together and for all the speakers for sharing their thoughts. So what I wanted to do today is just talk about three things. One, I wanted to talk about consensus R&D horizon. So this is why it makes, why we're still sort of like in what I think sort of like the middle, early to middle range of research in consensus and blockchains. I think there's a lot still to come. And this is a really fruitful field where there's many new discoveries to be made. And it's pretty important and valuable for the world to do this. And so I'll kind of talk about that. I wanna talk about some open problems. This is kind of a few things that are not well, there seem to be a lot of low-hanging fruit. And then I wanna talk about kind of some of the work that we have upcoming. This is more on the engineering side. So this is less on the research side and more on the engineering and actually kind of productizing or productionizing and then productizing some of the things that we've been working on. So I like using this image from, and this is a little bit outdated now but this is just a rough overview of what happens on the internet in one minute here on the left. And this is on the right, I think it's like per day. So this is just to give you a sense of a staggering scale of Web 2. This is an enormous amount of objects. A lot of these things are pretty large objects. So think of videos and YouTube as being large things. And a ton of the interactions across the world that happen use today, eventual consistency and standard database techniques. But overall they tend to reach consistency faster than many blockchains do today. And of course, most users on the planet expect a very hard level of consistency in their use of the applications, right? So if somebody likes a post or retweets a thing and so on, they definitely expect that to stick around. Now Web 3 needs to be able, for Web 3 to really work and for blockchains to really work, we have to reach this kind of scale computation. We have to reach to this level of being able to deal with these kinds of workloads. And just looking also at some other kind of cloud systems, you can sort of see the staggering scale that this might mean when you think about kind of the amount of storage that is stored by lots of different kinds of applications or the amounts of objects that that amount of storage represents. So we're dealing with an enormous amount of data and enormous amount of transactions and so on. So I think that today the scale of blockchains is just orders mounted away from where it needs to be. I don't think protocols can handle proper internet transaction volumes. I think there are no very serious internet scale applications yet. A lot of the asset trading that is happening is small relative to the larger spaces for trading and so on. And payments are still not as good as the cloud oriented global payment systems. And today no protocols can really handle mission critical deployment. So this means most deployments cannot really handle network partitions. If you're in a country that loses internet connectivity, you're host, you can't really interact with blockchains for the most part. You cannot really be in delayed tolerant networks. So if you are in an environment that has large latencies, you can't really interact either. And if there's some major internet outage and there's some big split, a lot of the chains would struggle. I think thankfully we have pretty good systems and a lot of them would recover gracefully, but they would definitely struggle for a while and a lot of systems would break in the middle. And I think in terms of transactional throughput, I think even the next generation blockchains that are getting developed now are not even close to what we need. I think we need on the order of billions to trillions of transactions per second. And really kind of the way we're gonna get there, I think is through things like charting. And Marco already talked a lot about this in the talk yesterday and kind of what we're working on this. One of the other pieces here is that a lot of the layer two approaches so far, especially when people try to do off-chain type stuff. So not quite the layer two consensus chains, but when people try to do off-chain type of things, those things are extremely complex and difficult to use. And they just don't think they're likely to be successful ways for building blockchain applications. I think the approaches of scaling with consensus and scaling to blockchains that are able to deal with much larger transactional throughput will end up working better. And so I think this is kind of like layer twos and beyond and also blockchains that can then have charting within themselves. And one other thing that I think is pretty relevant, a lot of the blockchain protocols that we're seeing today are not at a level of quality in terms of specification as the kind of standard ITF protocols that we're all used to relying on things like IP, BGP, DNS and so on. And so there's a long road ahead to really turn a lot of the blockchain protocols that we're used to today into really dependable parts of the internet. Just to give a sense of it in terms of, from Falkland's perspective, we wanna get to zettabytes of storage and we already have exabytes of storage. We wanna get to zettabytes in the relative linear future. We wanna be able to have like trillions of deals. We wanna have a lot of computation over the data and we wanna have all kinds of other applications and we wanna get to this level of kind of partition tolerance and horizontal scaling. The let's just kind of enable regions to operate and be able to disconnect from the rest of the world for periods of time. So all of what I just mentioned is stuff that I think many papers are tackling and many groups are kind of starting to work on the prototype solutions for but there aren't yet large-scale solutions that are deployed. But the good news is that it tends to be that computing platforms refine over time and we come up with new great ideas and we deploy them. So there's a lot of work ahead, but we can do it. And so I like using kind of this target where we can sort of see security and scalability on these two axes and sort of place the next generation chains slightly further up in the scalability pathway but very far away from the target. So I think we have several orders of magnitude to improve and this could be like a leapfrog. So it could be that in two years we hit the target or this could be a slower process where we kind of maybe add one or two hours of time for a few years. And just to give you a sense in if I was about to turn one-year-old and just in this space we now have a large amount of storage to deal with. We have a pretty saturated blockchain. We are pumping tons of proofs through it and we already are hitting kind of scaling requirements and we haven't even begun to tap into what happens when you add computation on top of the data and so on. So you already discussed kind of consensus the bottleneck of the centralized systems and Marco went into that. Some of the other stuff that we've been thinking about is kind of blockchain computation models. How do you do kind of cross-chart and vocations? How does that then translate into systems that enable you to kind of couple consensus to job schedulers in the sort of traditional sense distributed systems in the cloud have solved a lot of these scaling problems and with really good solutions. So let's try and use some of those techniques and apply them here. And so kind of what we're headed towards is this kind of storage and computation platform. And the good news is we can borrow from a lot of the standard distributed systems techniques to get there. These are the sort of the properties that I think are required for consensus protocols to be really great. So trillions of transactions per second, the fast local finality where you can do very fast, you can commit transactions in a locality and you have some kind of regional charts of some sort. And maybe those are kind of in some hierarchy up geographically all the way to kind of like an earth level consensus. You wanna be able to kind of be safe against national state attackers. You want the scaling of the regions and so on to meet the demand of users. And so kind of be economically motivated and you wanna be partition tolerant. There's all kinds of other things that we can probably add here, but the sort of, I think things that are required for blockchains to really reach internet scale. And so that means a lot of consensus work needs to happen. There's some other properties that I think are also valuable in terms of getting blockchains to be kind of foundational internet protocols. And so this means this is a lot of design work in the protocol space. So simplicity of the core use, generality, modularity, layering, all standard and good internet protocol design stuff. But I think that's fine if it comes later. I think it's sort of acceptable and good for systems to develop first and get to high quality use and high quality production use levels. And then after we figure out exactly what things should look like then at that point sort of refine them into the right shape. So, new ideas are here needed. You won't be easy, but it'll definitely be transformative to break all these, break through the barrier in the bottleneck and kind of have a lot of really great applications. So I'll touch on a little bit on some open problems. Maybe just breeze through these and then get to some of the kind of engineer work that might be useful for you. So I think Bootstrap in general across these protocols tends to be way under specified, tends to be insecure in a lot of systems. And this is a pretty difficult problem period here. There's sort of not quite any possibility result, but just an acknowledgement that is an extremely difficult problem too to do some kind of secure Bootstrap over the internet when you don't have information sharing. But I think that there are probably good systems that at least greatly level up the security and that should be deployed because nowadays people are depending on these blockchains for massive amounts of value and the Bootstrap systems are not actually good enough and you could mount some pretty serious attacks on many of them. Not all of them. I think a few of them, especially Bitcoin have survived attacks like that, but not all blockchains have really solved this Bootstrap problem. The second one is around kind of the broadcast channel or the gossip channel for transactions. This layer is just not very secure. There's been a number of papers already about this and so on. But again, those things haven't really made it into production use at larger scales. And it really seems like an area ripe for attacks at a large scale. So this is ISPs and nation states can definitely attack those layers. And it seems like if we focus on that area and we solve it with strong distribution systems or cryptographic primitives, we could lean into things like Byzantine broadcast. And if we do Byzantine broadcast in the transactional layer, then maybe consensus is not required at a higher layer. And so maybe if you do Byzantine broadcast in that layer, maybe you can clear transactions in a kind of a different way. And there are a few projects that are sort of like headed in this direction and they're starting to layer these pieces. But again, they haven't been productionized and deployed at scale. So definitely promising work, but I think it'd be really amazing to see one of the major blockchains sort of about this kind of thing. Yeah, this was said yesterday and it was really cool to see, I'll talk about this. But I think in general, just memples tend to be overlooked, just how transactions are described in memples and how they are cleared, algorithms for distributing them, for linking them and so on. Like the dag memple idea was really cool. I think there's probably a lot of other things that could be done here and sort of couples with a broadcast channel. There's also things around, oh and by the way, the memples are gonna get way more complicated once you have applications that do computation across too many shards. So now once we deal with massive scale of computation and massive scale of transactions, the memples are gonna get way harder to deal with. So they haven't been much of our problems so far, but they're definitely gonna become a much bigger thing to work on. The next thing that I think it's really important to do is that we need to get blockchains to be proper asynchronous protocols. The blockchains of today are not asynchronous. They tend to have a number of like, they are either completely synchronous protocols or they're kind of like in a partial synchrony setting or they pretend to be asynchronous but they're not really because they have some estimators. So for example, like Bitcoin in the Nakamoto consensus doesn't quite embed time in the actual kind of like proof of work calculation and so on but there's time embedded in the estimator of power and like kind of like the two week retargeting and so on. So there's kind of a synchrony assumption there. It's much weaker, which is great, but it's still not perfect. And I think it would be really amazing to be able to get to at least one or two blockchains of large scale that are deployed that are fully asynchronous and able to tolerate massive failures of the internet. The major economy should not depend on perfect connectivity and if they do then they're kind of good at all in some ways. The last thing I'll mention here is VDFs. So VDFs are kind of around the corner. There's like good designs. There's some hardware that the people are starting to develop and this will be really good for randomness, for anchoring chains, for anchoring proofs and other kinds of artifacts. And it'd be really, really great to kind of get to a really low AMACS VDF so that we can then start using them in blockchains. I'll mention two other kind of families to work. So I think we're now approaching the area of being able to do kind of like EC2 style or Amazon Lambda style computation in blockchains. This is a pretty difficult thing to do because people can't deal with the kind of like three partly unique sort of confidentiality, verifiability and high performance. And those three things are pretty hard to get. And so most of the computation in layer twos and so on and rollups that people are doing tend to give up on one of those usually performance. But I think for us to really reach internet scale computation, we're gonna have to enable really high performance applications and so the cost that we pay is gonna have to be bounded by, I don't know, like a factor of five or maybe 10 but certainly not what it is now. And so I think, but I think we're getting into the realm of being able to do this. And so I think it would be really great to start seeing blockchains that tackle this problem. And consensus matters here because most of these systems deployed around the world tend to rely on consensus as one of the critical components to be able to schedule the jobs and so on. And by the way, I think a homomorphic encryption is probably gonna start appearing finally like the again performance not quite there yet, but in the blockchain space, it might actually make sense to do FHE. There's a really cool project that actually has a type of FHE that maps well to machine learning. So you can actually do private machine learning in blockchains in like a not too crazy performance setting, which is pretty exciting. And then there's also kind of a CKSNAR computation that's coming around the corner. The other version of this is databases. So just like we can do job scheduling and so on to kind of like deal with the traditional kind of issue and computation jobs and kind of really build that part of the cloud. Blockchains don't yet look like databases. There's a few projects that have tackled this and tried to create it but they haven't really gotten strong adoption yet. And there's sort of like a gap that might be product gap, might be a systems gap, it's not really quite clear. But most of the applications on the planet tend to use these kinds of database abstractions. And so for us to really kind of, for Web3 to really enable Web2 to migrate over somewhere along the way, we'll have to have blockchains with consensus, with transactional, with standard transactions and then some standard database type of interfaces. And this is where kind of privacy will really matter for a lot of applications require privacy. And so the layer two is that kind of a couple high throughput and high performance with privacy might be really well positioned to kind of solve this kind of database problem. And I think this kind of thing is going to be really, really impactful. Cool, so I'll give it a little bit of a brief into kind of some of the things we're up to. PL in general is trying to drive breakthrusting computing to push your mandate forward. We work on a number of things, Paco and IPFS, the BPM number of projects. We work with a number of labs and so on. The way that we approach research is that we tend to think of kind of this whole pipeline from basic research all the way through refining an idea to kind of really productizing it and getting it into something that you can actually use some kind of like gadget or software or product that you can deploy and then where people can actually use the tech. We tend to see the world as in this sort of like based on looking at a lot of industrial labs and so on and kind of the actual process of technology translation, most of the research, most of the research and development that happens to projects tends to happen after the great core insight. So I tend to be the sort of academic credit sort of goes primarily to sort of like the core insights and not really to kind of like all of the hard work and it's like that I did this to refine a core insight into something that's actually broadly usable and that it's going to be kind of like fit problems very well. So we tried to approach this R&D process of getting things through this translation pipeline all the way into the market and this is how you can actually sort of accelerate the rate of progress. You heard from our PSRAE on consensus lab and all the exciting stuff that we're doing there. We're also looking at this blockchain computation models that I was describing. We're looking at things like Snarks and scaling proofs and starting to do kind of a computation with Snarks and so on. So it's a pretty general competition with Snarks and I think Franklin right now is still the largest deployed CK Snark network today. So that's a pretty interesting thing. Some of the engineering things that we have in the pipeline include, we're starting to think about what smart contracts on Franklin look like there's a number of groups working on this at the moment and we're sort of discussing and converging on what would be a good solution. We're kind of evaluating a wasm oriented runtime where we can plug in other runtimes like EVM and so on. And we would have IPLD as a native component so you could have content address code directly there. And we wanna do kind of cross chain invocations in kind of the airline actor model. So you can sort of reason about the cross chain invocations easily. We wanna develop kind of a rapid prototyping framework for blockchains. We sort of extracting a lot of the code from Lotus into a thing called Utico, which is kind of like a more general version of the flower Lotus that can enable kind of rapid prototyping with consensus lab. And if that is successful, if that project ends up being a pretty usable platform for others beyond us, that this might be like a useful tool for everybody here to be able to kind of prototype their new consensus protocols and so on. Just kind of drop in a replacement consensus protocol into a full blockchain node that you can deploy and test with. It's kind of early days still, but this could be promising over time. And like Mark said before, like there's a lot of stuff going on. There's everything from kind of grants and RFPs. We tend to be highly collaborative. So we give a lot of grants and we post RFPs. We work with a number of other groups. Also we have a number of open positions in Consensus Lab and that's growing. So if you're interested in joining us, definitely talk to us. And if your system and project is reaching a spot where it might go into adoption, we can also be helpful here. So a whole range of what we do is help technology get adopted. So if you're starting to think about productizing or use case and so on, we can be useful there as well. Great, so that's it for me. Thank you very much.