Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Juan Benet: Protocol Labs – IPFS, Filecoin and the Vision for a Decentralized Web (Part 2 of 2)

Episode Date: December 1, 2020

Filecoin is a peer-to-peer network data storage network, with built-in economic incentives for storage providers. It facilitates open-markets for storing and retrieving data, in which anyone can participate. Users can pay the network to access storage space, which can be encrypted, replicated, and highly available. After years of development and iteration, Filecoin recently launched its mainnet. The long term vision of the protocol is a fully decentralized future for the web. Juan Benet, Founder & CEO of Protocol Labs, returns for the second part of this 2-part episode. In this show we deep dive in to the technical aspects of Filecoin, how Juan and his team decided to design it, and the types of projects that are building on top of it.Topics covered in this episode:How Filecoin works under the hood and the life cycle of dataThe role of miners in the protocolThe bridge between Filecoin and EthereumHow the economics of Filecoin were designedHow governance works in the Filecoin networkThe Filecoin FoundationThe projects that are building on top of FilecoinJuan’s views on blockchain scalability and Ethereum 2.0, and the challenges Web3 facesEpisode links: Filecoin websiteProtocol Labs websiteIPFS websiteEpisode #367 with Juan Benet (Part 1 in this series)Episode #100 with Juan BenetFilecoin on TwitterJuan on TwitterSponsors: cPanel: cPanel's WordPress Toolkit is the all in one solution that makes hosting your website easier than it's ever been - https://epicenter.rocks/cpanelAlgorand: Learn more about Algorand and how it’s unique design makes it easy for developers to build sophisticated applications - https://algorand.com/epicenterThis episode is hosted by Brian Fabian Crain & Friederike Ernst. Show notes and listening options: epicenter.tv/368

Hi, I'm Sebasti Inquicchio and you're listening to Epicenter. The podcast will re-interview crypto founders, builders, and thought leaders. On this show, we dive deep to learn how things work at a technical level and we fly high to understand visionary concepts and long-term trends. If you like Epicenter, the best way to support us is to leave a review on Apple Podcasts. And if you're on a Mac or iOS device, the easiest way to do that is to go to epicenter. Dot rocks slash Apple. And if you're new to the podcast, be sure to subscribe on Apple Podcasts, or wherever you listen. Today our guest is Juan Benet, and this is part two of our two-part interview with Juan.

So if you haven't heard part one, I would definitely recommend you go back to last week's episode, that's episode 367, to get the full conversation. Part one focused on IPFS, and part two is focusing on Falcoyne. And here, Brian and Federica went deep with Juan into the intricacies and complexities of that project. So of course, they discussed the high-level and long-term vision of the project. the project, the technical underpinnings of how Filecoin works, the role and influence of miners on the protocol, its proximity to the Ethereum project, and how it's been inspired by the Ethereum project and its structure, how it was design and the complexities of designing systems

at this scale, the Filecoin Foundation, projects and use cases being built on Filecoin, and so much more. I really enjoyed this conversation. I think Juan is such a thoughtful thinker in the space and getting an update on this project, which we had first talked about five years ago, was definitely due. What's great is to learn about the ecosystem that is forming around this technology stack. So Juan talks about an ecosystem of investors that are interested in projects that are built on Filecoin. And I'm really looking forward to the day where the Filecoin IPFS stack is a viable alternative to the Azure's and AWS's and Googles of the world for, building production apps. And given how things are evolving, I don't think that that future is as far off as we think it might be. Anyway, if you're building websites today, you're probably using

one of the big cloud providers. And there's a good chance you're using WordPress. I mean, it powers like 80% of the websites on the internet. I've built a lot of WordPress websites. And one of the most frustrating things has always been DevOps. Well, thankfully, the folks over at C-Panel have built the WordPress toolkit for C-Panel, which is a tool that makes it easy for developers to manage their WordPress infrastructure. I'll tell you, bit more about that during the interview, but if you want to learn more right now, you can go to epicenter.rox slash C-Panel. And a couple of weeks ago, our friends over at Al-Grand hosted a great webinar to help developers build sophisticated defy apps. If you enjoyed that, you'll love

their after-hours series where blockchain developers can meet with their team and community members for informal conversations about Al-Garand. If you want to learn more about that, you can go to Al-Garand.com slash Epicenter, but I'll tell you more later on. For now, here's our conversation with Juan Benet. Now let's talk about Falkoin. Falkoin is the incentive layer that kind of brings it all together. What happens under the hood? Say, I am someone who wants to retrieve some content that I know is somewhere out there.

So basically, what would happen, whom would I pay, who is incentivized by what? What are the crypto economics going on here? Yeah, I got it. Yeah, so basically you're saying, hey, like, let's walk through kind of like the life cycle of data and kind of like follow it and so Yeah, so maybe let's start with, I'll describe three. So first, let's think about adding capacity to the network, then adding storage. So, you know, a client hiring a minor to add some data. And then the third is another client kind of retrieving some data that exists there.

So in the first case, you have a miner that has storage to provide and walks up to the network and pledges a certain amount of sectors. And a pledge is a commitment to the network that you're going to store a certain amount. you're going to add a certain amount of capacity, and you're going to produce some proofs for that capacity. And you also have to kind of, because this is related to consensus, you have to have something at stake here. You have to,

there's certain conditions in which there might be certain kinds of attacks that you could play. So that includes kind of a deposit of a phalcoin. So a minor adds store to the network, so adds some actual capacity, then gets a random seed from the network to store some data and kind of to produce a, to kind of seal

what is right now an empty sector source. It's just, you know, capacity. And this is, you know, kind of a sector today is 32 gigabytes and then, you know, there'll be kind of variable size sectors in the future and whatnot. You know, A minor might walk in with, say, a terabyte or something like that. You divide that terabyte into, you know, 32 gigabyte segments and you now, you know, seal all of these segments.

The sealing process involves doing a proof of replication that you actually have that capacity to provide to the network. And as a minor, you kind of have now signed up with a network for this capacity. In addition, the minor kind of sets a an ask price, which is how much their storage is going to go for when clients kind of are going to hire that storage. What will go for right now is there's sort of a global ask price. So a minor, most of the use cases, miners kind of have one price and that's it. in the future we anticipate, we want to have a flexible and fluid ask model where miners can give you many different kind of prices for different tiers of storage and all the kind of stuff. But for now, sort of like a very simple one price for all the storage.

So at that point, kind of the miner has, you know, committed to a network to sort of this, and now other parties can view it. So now along comes a user, a client, and says, okay, great, like, I want to store this data. And so the data, you know, they can, just add it with various different kinds of tools, so they can first add it to IPFS and get a hash, or they can add it with the FalkoN, with like the Lotus client, which is kind of one of the main Falkan implementations,

or a bunch of other tools that speak these protocols, like textile powergate or Slate, which is a consumer-oriented application. There's a bunch of other different kinds of things. And now of the storage that's been added, you can now hire, you can now kind of create a deal to hire a minor, to back this

back up this data. And that deal is sort of a relationship between a client, a single client and a single minor, and a single piece of data. So it's kind of like the unit of agreement. And as a client, you probably want to do this with multiple minors

because you want to replicate your data with multiple different parties. And so you now send your data over to, you know, you find these minors in the network by using this a number of ways. You can either enumerate them from the blockchain, and you can find them in a block explorer. There's a bunch of tools that can show you what miners and what ask prices they have.

And so you select which minor you want, and you could be maybe price sensitive, but you might also take into account other important details about the miner. So, for example, they're kind of like reliability. There's a different kind of kinds of features about the miner that get tracked by the blockchain and can sort of give you a score. Right now there's no emergent score that everybody's using yet, but you could build these kind of like

dread rating style numbers for miners so they become kind of like a very simple way of selecting minors. But you know, Klein right now chooses a minor and sends their data over to the source provider. Once the source provider receives it, the deal is completed and the miner

publishes the deal into the network. There's a bunch of operations that happen underneath the hood in order to like actually make that work. There's kind of some preparation of the data that has to happen in order to make it easy to prove and so on. And definitely the different sizes of the data really matter. Right? So if you're sending a little bit of data, say a few megabyte, a few kilobytes or megabytes, that's going to be, that kind of distribution is very different than if you're

sending gigabytes or terabytes. And so, for example, in the smaller scales, that just, you know, it's a very simple protocol where right away, you know, can just send, send the data over and make the deal and whatnot. As a user, this is completely hidden from you. You know, the client and the minor doing this, the software is doing this under the hood, but the users themselves don't have to be exposed to all of this going on under the hood. It's kind of like a, like a Bitcoin transaction or an Ethereum transaction. There's a lot going on happening under the hood for a transaction to like move to a certain place, get validated, execute and whatnot, but all of this kind of hidden from the actual users. By default, this is not encrypted, right, the data.

It's up to the clients to decide on the encryption structure. So, so, So by default, the data sort of gets pseudo-encrypted. It's not encrypted in a, we don't call that encryption because that implies that it is hidden from the world. There's a lot of data that's public. And so you need to allow people to store data that is in the clear so that public data can be used. But most, you know, PowerGate and other tools and so on, just encrypt all the data ahead of time. So, you know, if you are storing an application data and so on, you encrypt it first, and then

you send it to the world. Think about it as like the client software gives the minor what they want the world to see. And so if you want the world to see a public data set, then you should give in the clear. If you want them to have an encrypted thing, you can do that. We've also thought about moving to a world where

the data itself anyway is stored in model analogous to encryption. It's not exactly encryption, but it's analogous to it, and the data itself is dispersed and so on. and it's so that it's provable and whatnot. But we've considered kind of doing public data sets by using either convergent encryption or encryption where the public key is like, you know, sorry, the encryption key is just zeros or something like that. But it doesn't necessarily benefit.

I think it becomes very useful to be very clear about when there's encryption and when there isn't. And so far, like, that's been the structure that we've followed. Because there is this important utility of being able to have these public viewable datasets. But yeah, the tooling itself, you know, defaults to, you know, if you're adding data, you know, user-oriented tooling just defaults to encrypting all of it. But yeah, now that you've given the data to the miner, like they publish a deal into the network, and the miners now schedules that deal and that data to be sealed into a sector. And there's a scheduling piece here

because when you hire a minor, you're hiring for them, you know, for some amount of data. And they have to pack that into a sector. And a sector has a fixed size, right? And so they kind of minus collect a bunch of pieces from a lot of parties. And then they take all of that, assemble it into a sector and seal it all together. So, you know, think of it kind of like the mental model is think of a large storage container. So think of like a normal, you know, one of those shipping containers that you see on like ships and so on. And so your stuff could be the whole container or it could be smaller than that.

And or if you have bigger stuff, then it gets like partitioned off. into multiple search containers. And yeah, definitely if you, for example, want to send larger amounts of data, if you want to send terabytes or petabytes, then sending it over the internet is probably a bad idea because it'll take you a very, very long time. And instead of that point,

you want to, if you are at that scale, what people end up doing is, you know, contact the miner, and you figure out which miners you want to go for and you contact them, and you initiate a deal, but you now have to ship them the data physically. And that means like you send out, send them a drive, and then they get the drive, they verify that they actually got the data and they plug it in.

And this is a very important piece because the vast amounts of data in the world are moved around this way. They're not moved around over the internet. It's moved entirely off the internet through physical media. So packaging is one of the main avenues, but many large clouds also provide the support where they'll, they'll send, you know, I think like Amazon does this, where they can, you can schedule a truck to come to your business and, like, get a bunch of drives and send them to Glacier. Right. It's like, you have to fill that use case. Once you hit Xabytes of storage and like the large amounts of data, you have to allow people to have this offline first oriented way of moving around data, which is really cool because it means that you can not only move large amounts of data, but it means you can, you can start moving things in ways that are like, less expected by parties trying to predictively figure out all the parties that have. Whenever you don't rely on crossing certain borders on the internet, it's kind of like a really useful feature because it also means you can be, for example, partition tolerant, right?

So this isn't the case today because Falcon has one blockchain and you can think of it as kind of like one single singular region. But in the future, as scalable chains arrive, and this is kind of where Falcon is headed, being able to split into different, consensus regions that map to different regions of geographically so that you can be partitioned tolerant, so that you can continue to make deals and serve stuff and so on while while you're partitioned from the rest of the world. Because partitions in the internet are pretty frequent. Today already, you know, if you're it is stored in a minor and you can still talk to them,

it doesn't matter that you can't talk to the rest of the network, you can still get your data from the minor. That's an entirely off-chain-oriented transaction. Yeah, so let's say I have a bunch of data and I, you know, Federica is a minor and I've now shipped her, you know, some big pile of data and that now basically be, you know, in some level the thing you're describing, right,

there is actually this kind of, you know, direct transaction or like direct connection, right, between me who wants to store the data and, you know, her who's the minor. So Filecoin, what does it add in this scenario? Is it basically that she has to put up some collateral and then the file code network enforces that she actually does store it in the long run? And then also that there's this kind of like guarantee that, you know, other people can retrieve the data. And again, she has to kind of like guarantee that level of service. Exactly. Yeah.

So all what you described. And those are, you know, really critical components because, you know, today people trust the big clouds because of that reputation. and because you can trust them to continue storing your data, right? You're many smaller. Think of the kind of like the hotel and Airbnb world, where before Airbnb came on, you totally could go and stay in random people's houses or the idea that you could like,

how do you find them, how do you trust them? Where's the guarantee that you're actually going to be able to, you're actually going to have a place when you get there and people are going to receive you and you don't have good pictures of places or how do you guarantee good behavior that they aren't going to steal yourself in the middle of the night or something?

All of that before Airbnb was really hard to establish. It definitely happened, right? There were a lot of people traveling around this way, but it was a way smaller amount of parties and there was a lot more risk to it. So when Airbnb came in and created a marketplace that standardized the entire flow and standardized what it meant to be on the supply side

and standardized what it meant to be on the demand side, and build a bunch of tooling to add some amount of reputation systems to it and so on a verifiable around the pictures and whatnot. It just sort of cleaned up the entire market and greatly expanded its potential. Suddenly tons of places could be online. So if you have a bunch of storage and you want to kind of sell it online, how do you go about doing that? Similar to, you know, if you have a spare room, how do you go about selling a night in that room without a marketplace?

And so that's, you know, one of the really critical components is, You need a marketplace to standardize and create a protocol for how all of these interactions are supposed to happen. And you solve a bunch of hard problems that kind of really add a lot of value. Like, you know, the guaranteeing that the storage is going to be there in the long term. Like, that's a really critical component in any kind of storage relationship. Having a network that's large enough to accommodate a large use, right? So if it was, you know, if you were kind of browsing around individual websites and, you know, you hear about somebody having, like, 10 terabytes or like

one petabyte. They're like, well, should I store my data with this group or should I just go to Amazon? That's a very simple choice. But if you insert set ourselves dealing with one large network and you can sort of expect the same kind of quality

of service across it or you know some amount of variability between it but you have a standardized protocol for it, then you're totally able to trust a lot of service providers that can come into that marketplace. So it's really about kind of providing a way for the vast amount of supply out there to come together and aggregate into one

marketplace that then clients can do business with. I've been building WordPress websites for over 10 years, and the most frustrating thing has always been DevOps. I'm talking about deployment, maintenance, backups, and database management. I've lost so many hours of sleep doing WordPress infrastructure management. If you've been building websites for as long as I have, you're definitely familiar with C-Panel. They've been providing web hosting management software. for 25 years. Well, they have a new product. It's called the WordPress Toolkit for C-Panel, and I've been given an opportunity to try it out. It's really cool. It makes managing your

WordPress websites really easy. You can manage multiple WordPress sites from one dashboard, and you can manage users and databases too. And because all your websites are managed from a single interface, you'll be more efficient. This is really useful if you're running multiple environments like staging and production. The WordPress Toolkit can also apply security settings and policies to all your sites at once so you can harden and protect your company's website. There's a free light version and a deluxe paid version that has added features like website cloning and smart updates. That's also great if you're running multiple environments. Anyway, if you're doing anything with WordPress today, I would really encourage you to check this

out because it'll make your life so much easier. To learn more about the WordPress toolkit for C-Panel and be informed when it comes out, go to epicenter.orgs slash C-Penel. That's C-P-A-N-E-L. We'd like to thank C-Penel for their support of the podcast. So the Airbnb system kind of evolve gradually, right? So basically they have a customer support hotline, and if something goes wrong, you call them, and basically worst case, they give you your money back and you go look for a physical hotel wherever you're stranded.

So in a way, designing a decentralized network is fundamentally different in that it's kind of important to get parameters right from the get-go. and there's a lot of parameters. I mean, pertaining to, you know, the staking and the slashing and, you know, livenous guarantees and so on. How did you go about designing those economics? Great question. So one part is just figuring out what mechanisms do you need.

And a lot of that is thinking about the interactions and the flows between parties and what are the value flows that are happening. What guarantees you need to establish? think through many, many kinds of layers of potential attacks that might be possible. What are the assumptions all over the place? You want to minimize any kind of trust and make the transactions themselves very viable. And so that map to things like producing proofs or replication so that you can guarantee that the storage is actually there. And it map to things like an ongoing reverse face time where you can verify that the stuff is not only was there initially, but continues to be there over time.

and in map to mechanisms like what are the fee structures and the punishments that need to be the fees and punishments for bad behavior in the network, right? So if a minor loses data or things like that. And one part of this was designing, first you think about all these value flows, you think about the mechanisms, then you start thinking about what are the possible fees, not only fee structures, but value flows. Some things have to be proportional in certain ways. Some things have to be at least a certain amount. Some things have to be markets and kind of set by various different parties together. Certain things have to be estimators on network activity.

So there's really a very large amount of space here and a ton of parameters. The way we want to know about this is a large combination of analysis on individual mechanisms themselves and then couplings of mechanisms and so on further. plus then a whole crypto economics effort to build using both simulation and kind of like larger scale analysis frameworks

for figuring out the fee structures that would yield good results, meaning one part of this is thinking deeply through the problems and coming up with actual analytical expressions that tell you what the fee structure space has to be. So you figure out all the constraints between these systems,

systems of components and mechanics, and you kind of narrow down the space of possibility, so that gives you some kind of operating range. But that doesn't guarantee that it's going to work. It just kind of gives you some sense of what the constraints have to be. From there, some amount is also putting it into engineering and development and actually running it live. So we did a number of large-scale network tests with many miners to figure out what kind of operating parameters were workable in a number of these things. You know, theory is one thing. Practice is something very different. And, you know, you learn a lot by actually putting things directly in use.

But, you know, one big area of this was a large simulation endeavor that we undertook to, figure out what a bunch of different mechanisms and parameters have to be in order to yield good results. And this is kind of a very large effort with a lot of people, both within and outside of PL. So this includes various different teams within PL, but also. also a number of external collaborators in academic environments and a really awesome group called block science. We've been super helpful in building a lot of the, doing some of the simulation and analysis. And a number of research groups that we collaborated with for many years on different parts of the protocol. And so you end up with like a large mechanism design space and a bunch of parameters that you then have to make sure play nice.

And this is probably one of the biggest hurdles for not just for Falkland, but for the entire Web3 spaces. it is extremely difficult to build these kinds of larger-scale systems that do something more complex because the state space blows up exponentially. And kind of like what the parameter space that you have to search through really becomes very, very large. And a lot of it is you can easily end up with mechanisms that are too fragile, where maybe the operating range that you have is actually quite small, but some other mechanism couples within a weird way. And it's kind of like causes this space to oscillate in a weird way.

and maybe kind of like actually breaks things. So part of the output is like once you do a bunch of this analysis and simulation, you end up realizing that some mechanisms actually have to change. So not only do you, not only say about parameter setting, sometimes you end up having to change mechanisms to arrive at a much better, more stable construction because simulation just showed you, both either sometimes just directly in analysis or simulation shows you that this is actually like a bad system design because

it is too likely to, like, you know, most of the cases that you check are failures, or it is, maybe it is not, maybe it's kind of fragile. I don't know if you're familiar with kind of like the fragility versus anti-fragility way of analyzing systems where some systems are fragile. Once you kind of push them in certain ways, they will tend to, and push them out of their sort of normal comfort zone, they'll, they'll, they'll, they'll tend to break. Other systems kind of respond more naturally to kind of those stresses and can recover from those stresses. better. So that kind of lens of fragility versus anti-fragility, you can apply to this. And in your analysis simulation, you'll be able to kind of distinguish which mechanisms tend to be fragile and kind of remove them, because fragile mechanisms will lead to attack vectors and will lead to, you know, they might work for now, but once somebody changes something, then you might get into

a bad state. Or, hey, actually, you think it at work, but there's an embedded hidden assumption somewhere that you never expected and something that actually doesn't work. So it's a highly complex endeavor to build an economy like this. I mean, I think something like the, like Ethereum is similar in that when you think about all of the different mechanisms that are at play and the gas structure and so on, and in Ethereum's case, a lot of this kind of evolved over time and parameters were set and improved upon over many months and that kind of scaled with usage. And even kind of like the gas model is is kind of going into a major reworking with, you know, EIP 1559. And that, you know, in Ethereum's case, I think it's able to ship in it with a much smaller

amount of usage and then over time scale. We weren't, we unfortunately did not have that luxury, like right away, because we're kind of now in 2020 is supposed to in 2015, there's a lot more attention in the space as a whole and in applications like Pathcoin. So therefore, just from day one, we're going to get a much larger. scale of usage. So we had to get a lot more right from the get-go, which was definitely a harder, larger bar, but it made it, you know, we now ended up with a much more robust thing. One of the cool things is, like, we're actually shipped, shipped EIP 1559. Like, that's the

gas model that we use. And it actually works really well. It just leads to certain kind of really fast base fee spikes that, you know, food for thought for anybody working on this area of gas modeling and so on, really good structure, but leads to kind of like some spikes that make some people really unhappy, and it's easy to kind of run up the base fee. So we are getting a lot of data, I think it will be helpful for the Ethereum community as well. But anyway, there's like a large, complex space. One of our outputs on this is that this is an area where a lot of tools need to be made. So we had to build a bunch of internal tooling to, you know, all kinds of tools to analyze things in parts or as a whole system and kind of like simulation frameworks to be able to model this

kind of economic system. And this is an area where we definitely want to go back to this and think about what kind of tooling would be really broadly usable by a large number of groups to really kind of, you know, kind of analyze in-depth how most of these economic mechanisms should work, but also what's more important than analysis, I think, is helping generate them. So I think this is where this whole Web 3 world is at a juncture similar to where I think chip manufacturing was when it transitioned from kind of like human design to computer designed chips, where the constraint space got so big and the difficult to problem kind of scaled to the point where people needed to write software to do all of the chip layout.

and solve a bunch of problems that previously, you know, they weren't being expected humans to solve, but now computer stats have to solve just because of the magnitude. I think we're definitely well in that space where now most crypt economies that are going to see major usage really should be, should have mechanisms that are designed and checked in great part by programs. And the tooling is just not there and does not exist for any of us. And that is a huge area of improvement that,

I think if we had really robust tooling, we could shave months to years off of the development of every major project out there and all of the scalability improvements that are going to come into a lot of the projects that are out there now. So it's kind of a really open, you know, if any listener out there is interested in these kinds of topics and has been looking for a project or something like that, I think building really, really good tooling for protocol designers here is greatly needed. And that's something that we are kind of exploring as well as to, you know, if we were kind of doing this from scratch, what are the kinds of tools that we would have wanted to have and what are the kinds of tools that we want for future versions of Filecoin and other protocols and whatnot. And how might we build those? So either somebody else will go out there and build this or we'll have to. So ideally somebody else will do it and we won't have to do it because then we can just use your thing and that would be amazing. So please do that. Otherwise, we'll probably end up building something here at some point because there's a lot of utility to be had.

in making it way easier to build these systems. We're kind of hitting the limit of what teams of humans can do. It's just way too complex. And I think today you can probably, probably the attack space on contracts on Ethereum is so big that there are probably tons of exploits at the moment that are possible because of the combinations of contracts that are not explored because we just don't have the tools to explore them.

Meaning, again, the commentary explosion is so big that humans can't be expected to, figure this out. And so now we really need systems to help us find those and close those vulnerabilities before somebody kind of builds this tooling for bad and then kind of, you know, exploits it. But that would still mean that basically you would have to specify the intended behavior, right? So basically kind of like in formal verification where you kind of have to specify what you expect the business logic of the thing to be and building tooling for how we think about expected behavior. I mean, basically, it's kind of like a recursive problem, no?

Yes, and no, in that today, when people go on design protocols, they usually do it in their heads and on maybe paper and they kind of write on a notebook. And, you know, then later they'll go and transcribe that into a GitHub issue and will work in some other markdown document. And you'll get a bunch of kind of paper protocol stuff. And then at some point, people will, after many rounds of iteration and review, people will then turn that and start writing it into some implementation. Sometimes it's prototypes that test the validity of something before you do any kind of like hard engineering work for the real kind of production use. Many times it's just, you know, go straight to the production use and like start building it into the main client, which, you know,

that's going to be way slow, probably way slower, but because, you know, you're going to find protocol problems in and paid a big cost of putting it into the main thing. And then after all of that, you know, hopefully you've gone through enough rounds of analysis in the paper stages. And if you're dealing with economics, enough rounds of, you know, kind of larger scale framework analysis and simulation to really know that the mechanisms are right. And then you're going to like put it into production and use it and then hope for the best. And like, you know, over time kind of find problems and fix them. And that's kind of like the state of the industry. And I think that, uh, most of these protocols are big enough that you have dozens to hundreds of people working on them. And maintaining

the protocol space in one head is just not a thing you can do anymore. So what I'm kind of talking about is you need people to start working in software from the get-go. You need people to, when they're designing the protocol at the very beginning, you can greatly reduce the iteration cycle by doing very kind of straightforward modeling work that will kind of show that some mechanism is just not tractable or kind of won't fit with some other components or would um will not kind of function so it is something close to formal verification or kind of like the tLA plus style formal verification or something like that but but i think it's it's got to be just dramatically easier i think most of formal verification languages and systems are way too

complex for this use case. This has to be as simple as writing an expression in kind of observable or something like that, where you have a kind of full system design somewhere, and you are designing parts of the protocol, and it's a very kind of individual researcher oriented and individual developer oriented tool that enables you to kind of add components to the protocol, but it's not just one protocol. It's rather like you can think of a bunch of different versions, possible versions of the protocol with different kind of mechanisms, and you can test against all of these different combinations, and you can think through which ones end up yielding better results.

And if you can kind of couple that with simulation and kind of model checking across the whole thing, then you can greatly increase the speed of building something as complex as Ethereum and Vodon and so on. And I think right now, you know, kind of back in the day, the software industry face a similar counterint transition between writing software and tests versus the entire continuous integration system that we have

now. So today, you write code and you can not only write tests and unit tests for your part of the application and whatnot and kind of larger integration tests, but it is an industry norm, that all of that is going to get tested through a very wide battery of tests across many different kind of infrastructures before it gets deployed. And once it passes all of these performance requirements, then it will actually kind of ship, right? So if you've seen kind of the performance dashboards for Chrome or Firefox, that'll give you a sense of every single line of code gets tested across a really gargantuan amount of tests

that tests all kinds of things. And if you introduce accidentally a performance hit somewhere, everyone will know. You'll see all kinds of charts show you that this is going bad. And software has moved to this kind of design space and engineering space because that was a way to make the development of these kinds of large infrastructure projects so much faster, right? So something like Chrome or Firefox has hundreds of people developing

on that. You can't do that without that kind of tooling and that kind of testing infrastructure in place. So that's what I think is necessary for these protocols going forward. We need that kind of, the analogous version of that kind of testing infrastructure, which is not just the software. At this point, it's really the mechanism design has to be included in it because there's just way too much for individual researchers to be able to handle the larger complexity. And if you think that, you know, many Ethereum developers out there, and I'm saying Ethereum developers, because I think this is kind of like the kind of like largest smart carder platform out there with widest use. But this probably applies to most blockchains. Many Ethereum developers out there

kind of approach writing a contract simply, and they just kind of, you know, if they're, if they're, they're, they're right their solidity contract. And then they think about how, what exploits there might be in that one, and there's a bunch of tooling that helps you think about how to improve it and so on, and maybe check some important cases. You know, few groups actually think through, what are all the other mechanisms available to an Ethereum contract? What other Ethereum contracts are out there? And how is my contract going to get exploited by one of those out there?

Right. So am I accidentally creating a thing where somebody with flash loan capabilities is going to destroy the entire mechanism I just built or not, right? And, hey, today is flash loans. Tomorrow it's like some other completely different thing. And so you need a whole software CICD type version thing, but for the entire mechanism design space. Our friends over at Algarand are starting an office hour series. So every week or two, Algarand will bring together to team, partners, and community together

for a live discussion intended to provide you with all the answers and resources you need towards building useful, meaningful blockchain applications. By joining office hours, you'll learn how to get started with command line tools and use the SDK and Rest APIs to help you build applications for use cases like crowdfunding, asset tokenization, supply chain management, and gaming applications. Each office hour will start with a theme, for example, smart contracts or writing contracts in Python, followed by an open Q&A and chat. So if you're building on a blockchain protocol that has unfeasibly high or unpredictable

transaction fees and doesn't provide you the speed you need, or if you work at a large enterprise or financial institution and are interested in learning how to build applications that can integrate with your current technology stack, or whether you have no blockchain experience at all and just looking to take the first step into learning something new, Algaran could be the right solution for you. To learn more, visit Algarand.com slash epicenter for developer resources and information about their next office hours. We'd like to thank Algarand for those support of the podcast.

I mean, the thing that, like this topic where it really struck me was that, well, There's this book called, I mean, book, it's kind of like a compilation of Satoshi's writing. I think it's called the book of Satoshi. So some guy went through, you know, all of the old Bitcoin talk and like all of the kind of things Satoshi had written and kind of like organized it, and it's really cool to read. And one of the things that really struck me when I was reading the thing was that, you know, Satoshi, as far as we know, right, he didn't anticipate like A6 and he didn't anticipate mining pools. And, you know, Bitcoin is such a simple.

economic design. You can hardly make a simple economic design for like a cryptocurrency. And then even with such a simple design, it seems like there was these, you know, major unintended consequences that have kind of worked out fine. But, you know, they seem to not have been predictable or, you know, you know, in retrospective we can see like, yeah, of course this was going to happen. But like, so then if you think of like more complex systems, like, you know, pretty much. much most cryptocurrency since then, and you know, especially things like Filecoin, but, you know, even Ethereum, right, where you have, like, different pricing for upcodes. Every proof of stake thing. Yeah, I think you're totally right.

This is such a hard problem and such an important problem to get right. And, you know, probably also you're going to have to have some, you know, some level of ability to respond. Actually, that's the question I want to bring up here briefly. is how does governance work in the FalkoCoin network? Yeah, great question. So maybe I'll address the kind of like a because of the flow of the conversation. I'll address the smaller case of how do you respond to problems and then kind of from the broader governance question.

So out of response problems is a really key thing for blockchains. And blockchains that don't address this directly and try to have a lot of value will not end. Well, in our case, the Falcon community. has sort of formed a set of... So first of all, there's... The parties running the network are...

There's a lot of miners that are maintaining the blockchain and we actually have a really good distribution of power. So many other blockchains are super centralized and in our case we have a much better kind of distribution overall with the power than many other networks out there. So there's a lot more kind of minors in the...

that contribute to, say, have the power or 75% of the power than in a lot of other systems. So it's one important thing, because it prevents many kinds of attacks being exploited very quickly. There's a number of network operators that have a number of communication channels set up and ready for problems. And there's a number of developers, both across various different organizations and companies that are pretty familiar with. There's four implementations. There's one main one that most people run today, but there's a few others that are joining very soon.

And a lot of those developers are kind of in the weeds of a lot of this. plus there's a few other miners that have development shops associated with them so there's a number of developers that those miners have as well there's kind of like this group of network operators and this group of developers and there's organizations that have set up

on-call rotations for the operators and the developers to be able to address problems should they emerge. So if there's kind of some problem and it requires addressing very quickly then we can figure what the problem is, as a community,

describe what the patch needs to be, discuss it on GitHub, whether it is fully publicly, if it's not kind of an exploit that's going to, if it's kind of like a natural problem or a well-known thing, or privately if it's a thing where there's kind of an exploit that's potentially

worth, you know, kind of exploit-worthy or something like that. And then kind of arrive at what a potential patch might look like and a number of people look at it and then it kind of gets agreed upon and then shipped out in a, a release and then that's a release of the code and then at that point kind of network operators and a number of the miners look at that release download the code upgrade their own set of you know if they agree with it they download the code upgrade and kind of go from there and there are kind of

upgrades that are just software only and then there are chain upgrades so chain upgrades require kind of a state transition and that state transitions are slower unfortunately and harder we had it as a requirement for space race to go through a number of really hard state transitions in very short-term cycles to kind of help bootstrap the community activity around this kind of work so that the community kind of got used to making important chain state upgrades quickly because if some major problem emerges, you need the community to be able to respond to that kind of stuff fast. And in the normal setting of cloud infrastructure where there's one company running things, or maybe two or something like that, coordination there could be faster. In a world with many

other stakeholders, it could be slower. In our case, we think that we're responding to things as fast, if not faster than other other kind of more traditional centralized systems. Because we've taken on the work of thinking about this as a goal for the network, and many miners and developers are aligned against that problem. And we have kind of emergency response protocols so we've set up in place for this. You know, thankfully we haven't had to deal with anything major.

I mean, knock on wood and all that kind of stuff, many other networks, even by our age, had already kind of encountered a bunch of problems. We've had a number of important improvements and changes that need to happen quickly, but nothing kind of super major. We will eventually, right? So every blockchain goes through very large,

kind of destabilizing hard problems. You know, Ethereum had many, there's so many blockchains that encounter these kinds of problems is just the nature of software and the nature of these systems. So the best thing is like a lot of preventative measures plus a lot of kind of fast response measures to be able to kind of solve the problem. So it's kind of like the, how does the pipeline network as a community respond to these kinds of issues?

And, you know, it's been really awesome to see the response in general from many different groups. I'm thinking of like individual miners and individual developers in different communities that have helped find bugs or helped come up with patches or submitted things

and ship releases and so on. Brought our question of how does governance work? Here we borrowed a ton from Ethereum because we reviewed a lot of different systems and a lot of chains and their approaches. I mean, we're super close to, in general, a lot of our communities shared with the Ethereum community.

We sort of feel very tightly made and collaborated a lot. But we sort of saw a really pragmatic feel and really kind of successful pragmatic structure to the Ethereum governance structure where it's kind of RFC inspired, so you have

like the normal EIPs and so on, and you have kind of like this, you know, strong idea of rough consensus and running code. And you have a good principle set in with the community that you are going to improve things and you are going to improve implementations pretty frequently and quickly, and you are going to come up with a bunch of standards and so on.

And so we kind of borrowed a lot from that. And so we saw it as a really good place to mirror a lot of like the really good, good lessons. And so we borrowed the improvement proposal structure, which again, kind of comes from Bitcoin and Bitcoin as well and standard RFC style inspired things. So there are five point improvement proposals and there's a, you know, anybody can submit a five point improvement proposal. And then there's, you know, a set of implementations and implementers that review those proposals and kind of are in charge of. of deciding whether to implement them into their implementations. But that doesn't necessarily mean a decision of like, they decide that an important change needs to land.

That's more of a leaving it up to the community thing because you have the standard structure that happens to no blockchains where developers might say X, but if miners don't agree, then it doesn't matter. People are going to run something else. And so you have that natural governance structure that emerges where you have, like these two groups of parties, groups of developers and groups of miners, that have to sort of, it's kind of like a bicameral system

where both parties have to, both groups have to agree with the change before it lands. So, FIPs tend to be discussed a lot by miners and developers and so on. Often this starts in Slack. There's like a Falking community Slack, and people end up discussing various different avenues of a problem. And there's all kinds of discussion threads that happen there. Then from there, it translates into a GitHub FIP.

And once it's in a FIP, people will then go and discuss it there. And then from there, we have kind of a weekly developer conversation that kind of goes through those tips and talks about which ones are slated for implementation and not and whatnot. And then from there, it gets scheduled into releases. And then from there, minors kind of voice. You know, by that point, if anybody, if any large group of minors and so on don't want to change, we'll have already been voice and it likely isn't going to get implemented because implementers, I'm not going to start implementing something. if it's not going to get accepted. And so you have this very kind of like rough consensus and running code feel to the whole thing.

It is not very formalized intentionally. And we thought that that was like a very good decision from Ethereum relative to a lot of other groups because it made it very easy for an urgent things to happen quickly that are kind of like non-controversial. And it gave the community a lot of voice for things that are important and should be taken slower. And so that's kind of like an important kind of

mapping that we thought was useful and valuable. Now, in the long term, we do think that on-chain governance systems are really valuable and really interesting. And Falcuin may end up with some on-chain governance structures in the future. The community in general is pretty interested in these kinds of things. But we haven't, we didn't want to kind of couple all of that risk as well into an already kind of like highly complex system. And so we'll once some of these on-chain governance systems get more fleshed out and

tested and work out, then the Falcon community will probably, you know, if it's valuable to adopt one, it will. There's also a foundation. There's the Falcon Foundation, which is taking on a lot of programs in the community and will help steward the long-term. There's a lot of things that you need a kind of like entity in the kind of normal human world to do and to help steward in a blockchain environment. And that's what the foundation is going to do long term. And so Berkola Labs is transitioning a bunch of programs over to the foundation to run there. The foundation is planning a bunch of other things that are really interesting and really cool and really exciting. And they as an entity have been kind of given some talks lately and

we'll luckily have a much larger voice in the coming weeks. By the way, I highly recommend you meet those folks. Really brilliant people involved with. with the foundation a number of avenues. Both they have really stellar amazing advisory board that has a ton of amazing people in, both in crypto and in internet, civil liberties space, like a number of people from the EFF. And also a highly recommend,

Marta Belcher is like one of the main people that kind of took on building the PATHelian. I highly recommend chatting with her. And then there's a number of operators that are kind of like running the foundation. They'll kind of help build out a number of important programs and help steer some of the kind of development groups and committees and whatnot. But, you know, kind of a lot of the principles go back to your kind of rough

consensus in running code and kind of like the will of, what is like the will of the community? So you can probably expect a lot of the standard tooling that emerges with systems like this, like pulling tools and and whatnot. Like being able to pull minors by minor power or by certainly token holdings are useful, developers. And like one of the things that we want to do is be able to pull application developers. So if you have a bunch of application developers and hearing what they have to say is really, really key. So we've kind of sketched out some polling tools that have these different constituencies. And so you can kind of get a sense of what people think about certain kinds of community decisions and whatnot. But you know, it's kind of early days.

A lot of this still happening in Slack and GitHub and kind of like the normal channels. Over time, as the network gets bigger and a lot more happens with it, we'll kind of bring in a lot of the tooling and systems that other groups have. So you were talking about the application developers, and I think this is one of the things that I would really still like to talk about. So there's actually a number of projects building on top of FalkoCoin. Can you talk about those for a bit? Yeah, totally.

And so there's a lot of the different groups, and they're coming from, you know, some groups are, you know, kind of came to Falkcoin from IPFS, and a number of them are kind of newly, newly jumping into Falkcoin. I'll maybe mention, so maybe say there's a kind of like set of larger developers that have kind of existing applications that are now starting to use Filecoin. And then there's a whole wave of new developers that are building on Pac-Con as like they're totally new applications. And that's also really exciting. So maybe I'll talk a little bit about both.

So in one end of the spectrum, there's, you know, kind of think of actually, there's one use cases, which I think is super compelling and really important. is one of my favorite application applications of Falcon. It's an application called Starling. And Starling is a system and framework for preserving really important and valuable cultural heritage data. And so that means there are some extremely important data sets out there that have extremely important cultural value to groups of people, where you really want to make sure that data stays around and you want to make that verifiable. And you want to be able to verify that that data is being kept around.

You want to verify how many, that there are a lot of copies around the world, that that data is not going to get lost. And you also want to verify that that data has not been tampered with over time. It's extremely critical that that data has not been tampered over time. And some of this kind of data is, you know, kind of important archives of documents and media and testimonials of important conflicts in history.

And so the starting group has been working with a number of other groups, including the Showell Foundation and a number of other, you know, Stanford University and a number of other groups, to build out an application that uses Falkoin to back up this incredibly culturally important, cultural testimonial data. That's super important and valuable. And one of the reasons that they really saw Filecoin and found it really interesting and really important for the use case was that verifiable. Being able to verify that the data is being kept around and who's keeping it around and being able to verify that it hasn't been tampered with.

It's such a critical component in all of this that that became kind of like an important kind of user and use case. And so that's been also extremely humbling for me and for a number of us working on FilePoint. to see such an important use case right away for having a significant impact on the world. So we'll see kind of where that heads, but that's a super valuable application and use case. Other users are, there's a number of DAP developers that are moving around their front ends that are right now,

hosted on already kind of address an IPFS, but backed up by either themselves or other structures, and are now starting to move it over to Placcoin. There's one range of applications around video that's super exciting where this is kind of coupling with, so there's a few experiments here that I think are really, really cool. But I'll mention one in particular, which is a combination of Falcon and Life Pier, where you can now, kind of like, drag and drop any video to this webpage, and it will get moved over to the LifePier network, get transcoded into all of the right important formats for the web, and then all of that will get put into. to Filecoin and then stored and distributed through Filecoin. So you have kind of like an into-end video distribution thing, you know, working with Filecoin and LifePier, you know, today.

And that's like a super, super cool use case. There's people working on live video. So on one part, it's doing video distribution using IPFS and Lipitiopi-Dipi of live video. Think of streaming use case. And then take the, as the video is getting generated, once the kind of livestream is over storing the whole thing and on Pac-Wan for the long-term. So then you're able to kind of view the log of the, view that video stream later on. It's kind of some of the video-oriented use cases that I think are pretty cool.

Then there's a bunch of kind of defy-oriented things going on where, you know, kind of, a lot of the applications that people are building right now and tools are for the whole mining community. So there's not only do you have applications that are using Falcon for something else, but Pacquint itself requires some tools and applications built for, for itself functioning, kind of like with a theorem, there's a number of applications there. So some of these include ways and structures for, you know, creating better organizational structures and financial structures for mining. And so one example is, you know, very standard defy loan oriented stuff where you have a bridge from Bitcoin to Ethereum. And then you can do a bunch of like loan oriented stuff and then back back, back to.

to Bokkwin, so miners can borrow Bacquin in order to use it for collaterals. But then also structures where you can have contracts for financing the development of mining operations, right? So it turns out mining operations in the larger scales are pretty involved in Nevers. You know, if you want to maintain a bunch of really high quality storage in a facility and whatnot, then you're able to kind of start creating some of the organizational structures and raise funding either by selling some of your cash flows or things like that. like that and this is happening in DFI in Ethereum, right? So there's examples of this and this

groups are exploring different avenues for doing this in kind of in this part. Another area that I don't think this is out yet, but is a pretty interesting thing is starting to think about cloud storage itself and being able to sell capacity in the future as think of being able to so any kind of important commodity in the world has got an important financial industry around it. So think of like being able to have oil and then have a bunch of different kinds of financial instruments associated with oil around it. So because we're commoditizing, because Falcon is commoditizing this digital storage on the cloud, people are building kind of structures where you could potentially start doing the same kind of financial instruments for cloud

storage on blockchain. So that I think will take some time to get going and kick off. because it requires a bunch of exploration around what structures are needed and whatnot. But imagine having the kind of predictability that you get out of other commodities, but you get that in kind of the digital source space. So that'll be, there's a whole kind of like interesting world because if that's what's happening with Filecoin, then that'll push that kind of activity about storage media to potentially happen as well. And so that's a whole, Falcone is starting to affect the storage media market, as you were describing earlier in some kind of important ways.

Building a bunch of different kinds of systems around Falcuan, there's a set of uses there. And then there's a whole category of new applications that, there's been a number of hackathons already where people are building a bunch of really cool things from games to social network. There were probably like 15 or 20 different social networks that I saw at this hackathon built using Thalcoin,

like different things like Twitter, things like more Facebook news feed and friends style things and messaging things and so on that are getting kind of experimented with. I think those things will take more time to really develop and flesh out into something that a lot of people can use, but already a lot of people are experimenting with and building these things kind of from scratch on thought, and that's super cool. And then there's a, yeah, even in that class, there were a number of people doing this kind of a live streaming work and video-oriented work.

There's another really cool one, which is this amazing use case around machine learning computation around data. So people store data in the clear on PowerPoint, and then they have this other tooling that they can then ship compute. So if this Falcon Miner is, like, equipped with this additional protocol, then you can ship computation to that minor, and they'll run it over the data so they have, and then give you the results. And all of that is hooked up in, you know, the standard Python tooling. So you can have, like, your normal, you know, normal data science toolkit, and then you just import a few

things in your normal flow, in like your notebook structure. And now you can both store data to file coin, but also kind of like ship computation to the nodes that are storing it. And so it's kind of like specific miners that are doing this, because not all miners are going to be able to, you know, automatically do this. This is kind of an additional protocol that they have to run. But that's kind of like a really cool example of what's going to happen once you start adding a lot of important data that you can compute on. And data has this kind of gravity element to it where it's way easier to ship the computation to the data than the other way around. Like you want to move the computation to data, do it there, and then kind of take the results elsewhere. So we think that this kind of computing over data store on file point is going to be a big thing in the long term.

And so we're starting to see the beginning versions of this and beginning use cases of people experimenting with stuff. I think those protocols will probably take a while to flesh out into something super scalable, but already you can store large amounts of data and compute with it really easily and really cheaply. Those are some of the cool applications out there. There's also just the idea of using the storage itself, right? So separate from application building, various different groups are looking at using talking data, you know, the raw data storage and so on. And that's pretty, I probably can't talk about any of the groups that I know about right now

that are considering in the larger scales. And I think one of the important things here is any kind of major groups are going to be experimenting. The network's super new. Like it just launched, the cycles for any kind of large petabyte scale usage are in the many. Think of like enterprise time scales where they're going to be experimenting with stuff for quite a while. And then they're going to kind of make any kind of public switch or whatever. And so those are going to be exciting and whatnot. But those are probably more a story for the future.

future, but there's already some interesting pilots that are forming and some pretty cool public data uses that I, that's kind of like more where my heart is, where a lot of the reasons that I started IPFS in the first place were around making it way cheaper and easier to backup vast amounts of important scientific data that's open access than anybody can use and can compute with, you know, like a versioning data sets and all that kind of stuff. And all of that is, you know, finally, then finally, I have a, I can point to a network that has vast amount of capacity to be able to. back up the world's most important scientific data and kind of provided super cheaply for people to use and download and compute with. And that's really there now. So now I think like the next important milestone on that journey is now starting to work with a number of groups to start adding a ton of those important data sets over into to Farquine. I'll mention one more, which I think is pretty cool.

I'm starting to see people doing pay-per-view videos. And so you can do like video, you store the video and do video distribution entirely through Filecoin. You can do like payment channel, pay-per-view stuff. And so that's also pretty cool. I mean, it's not super safe in that. And if you get the decryption key, you can probably share it out and whatnot. But a lot of the times this is more about friction than getting it super secure. So that's already kind of cool.

Cool. Yeah, I mean, it's great to see just how much there's going on and how this ecosystem is blossoming. So there's one other topic we wanted to touch on because, you know, before the podcast, we had briefly talked about it with you. And you mentioned already this kind of two answers. It was a blockchain scalability topic, right? And, you know, on the one hand, it would be interesting to hear kind of like your thoughts on how FileCon is going to scale as a blockchain.

But then also, you know, what are your thoughts on kind of blockchain scalability topic in general and specifically, you know, what are your thoughts on like EVE 2? and you know I think as we're as we're recording this actually I think like today or something like that the threshold the deposit threshold for eF2 has been crossed so you know this is like finally now imminent that you know the first steps towards the you know the full eith 2 yeah so um can we go back to this I just realized that I wanted to add one important bit for the community on on applications can I add that now and then and then go back to this one really important part of the ecosystem that's growing right now very strongly is this kind of whole life cycle of development of the hackathons and then people taking those hacks and then going into accelerators and then getting of those kind of people that kind of continue on to build businesses end up getting investments. So one of the really important signals in any kind of platform like this is how many developers

really care about this or trying it out and experimenting with it. And then how many of those actually build not just hack. but then go on to build applications and then get investment. And then a couple of that is like how many investors in the space are kind of investing. So that's something I think is super cool about Falcon is super early right now. And already there's been a bunch of hackathons, a bunch of groups out of that going into accelerators. And then from accelerators, there's funds forming entirely to build and invest in the Falcon ecosystem.

And so they're now not just investors in general, but there are funds emerging. that are just investing in Falcon applications. And so it's a really exciting and positive time for people to get involved. People that are maybe in between things or have an application that already use SIPFS and was maybe a good trajectory for Falcon. It's a super vibrant ecosystem at the moment. And it's kind of blossoming and growing a lot. And there's a lot of interest from other developers and from the whole kind of development

support cycle of grants and investments and so on happening at the moment. And so there's probably a bunch of projects that are getting built today and in the next few months that are going to be hitting, say, three to nine months from now. So because usually kind of a lot of these applications take a while to kind of get built out, go out there and then get users and so on. So a lot of the cool things that are happening at the moment will probably end up kind of being a whole wave of apps, say six to nine months from now. And yeah, so highly encourage people to kind of get involved. and one really great area where we hadn't really seen this happening elsewhere, but our Slack turned out to be a super active environment where I think there's many, I don't know how many thousands of different people

are there in different groups, and there's all kinds of activities around hackathons and, again, accelerators and whatnot, all happening in the same space, and so it's a pretty active environment. It's kind of similar to the world of different Discord servers and Ethereum community. So I highly recommend people. come and hang out and check it out. So the scalability question is super critical and important for the entire space.

This is something that I see as the biggest hurdle to broad scale adoption in Web3. So I think I kind of tend to think about it as the consensus bottleneck. So today there's just a ton of transactions I want to go through a really tiny amount of bandwidth. And most applications that consider using blockchains just run into this bottleneck. and have to start doing all kinds of crazy off-chain protocols or side chains or all kinds of really contortions of their application to make it work in the blockchain model. And so, of course, this has been a topic for a discussion for a long time. A lot of people are on it.

There's a lot of people trying to build much more scalable blockchain systems. And, you know, I would put it at the head of the pack there, Ethereum and Ethereum 2, the entire scalability effort in Ethereum 2 is, you know, the furthest along from many that I've seen. And I think the one that's tackling larger questions more seriously. So I think it's a really kind of a really critical project to watch and help out and going to help succeed. And so, yeah, it's awesome that, you know, we kind of just cross the threshold and, you know, the beacon chain is happening and now we're going to get to go towards all the sharding and so on. I think then in the long term though, if you kind of like zoom out for a moment,

and you think about computing infrastructure in general, and you think about the kind of how much data gets generated, again, is in the order of zabytes, how much of that is useful to store probably right now in the, you know, tens to hundreds of xabytes. That's, again, growing exponentially of that. some fraction of it is application data that requires really fast, basically consistency times, where people are used to chatting on an app, typing something, pressing enter, getting to the other person, and getting persisted into long-term storage, and never losing that.

And they're used to kind of operations on social network websites that, you know, they click a bunch of buttons and all of that gets persisted somewhere. building an application platform that can support that kind of a scale of use is not only non-trivial, but will require solving a bunch of challenges for Web3. So in some cases, you can segment some of the operations to be client-side only, and if you can do that, that's great. But there's a lot of operation that has to be whole network-oriented, and when you hit any kind of real usage, you're going to run against this limit, this kind of consensus-oriented limit. And sure, you can try to do a bunch of stuff off-chain,

but you end up having now two problems because a whole part of your application has to live on a blockchain. And then there's another part of the application that's on the client side and kind of a user interface. And there's another part of the application that has to live somewhere in between some other off-chain protocol that's custom. And that I think is not the way to go at all. I think that for Web3 to succeed in a long term in general, we have to hit a system that can hit millions of transactions per second and can get pretty good consistency and by that I mean, you know, sub-second style commits

where somebody can like type a thing, presenter and close the application, like, you know, in kind of human scale, like within seconds. And know that all of that was stored safely somewhere and someone's going to be, the other user is going to be able to get that and see that. and the application is going to remember their settings and whatnot. And doing that for billions of users in a crypto-native sort of way

is going to require that we have these like consistency structure built in. So for applications where it's really just between an individual and a group of people, that's where things like, there's these things called textile threads, which are part of the textile stack in the IPFUS and Falcon ecosystems, where you can sort of model a lot of your updates, into your application and into kind of like a thread of operations. So think of us having a chat stream or us sharing some documents with each other, having kind of like a Google Doc style experience,

and modeling all of those changes in that kind of thread and shipping all those updates to each other and to kind of some to file content store and backup in the long term and us being able to kind of pull that out of there and kind of use it. So there's a bunch of applications where that will work. But that kind of consistency does not require super, hard, rigorous kind of network intermediation, right? So we can do it like a Google Doc style thing.

If we have a protocol that kind of can see the updates and I can see my updates, you can see your updates, we can both sign them. And all we need is the log of operations to reconstruct that whole thing. That's easy and that's kind of, you don't have to build a custom off-chain thing for that. You can use Excel threads and be done. And so that you can now model in, think of kind of like a normal web developer experience without kind of thinking of any complex Web 3 crypto stuff and have some very simple primitives and very simple data model

that just works for developers and they don't have to think about it a lot. And that's kind of working now. But as soon as you have something where you need some kind of important business logic that users can't change and it requires some kind of like network operation, that's where you have to now suddenly put this into a blockchain or into a network of other off-blockchain but important validator type roles. And I think that's what I think in the future

is going to be entirely blockchains. It just has to be scalable systems. And again, I really think that that kind of, there is so much need for that kind of a transactional model that we're going to need to build systems that can scale to millions of transactions per second and clear very quickly. And I think that the way that we're going to get there

is by building consensus systems that can shard over time. as they get used in certain regions of the world, but where they're really mapped, they're not kind of just generic shards across, right now I think like the Ethereum 2 charts are going to be, you know, I think like a thousand, 24 shards or something like that, maybe 2000-something, I don't remember what the last number is,

but they're all going to be the same, and they're all going to be global. And I really think that if people start modeling these shards as being related to regions, you can do a couple things. One is you can speed up the consensus time because it means you can, you can go way faster in one region.

So doing consensus in one continent is way faster than around the whole planet. It's a speed of light issue, right? The Earth is pretty big. So you've got to wait a certain amount of time for propagation of information. If you reduce the size and say you create a region in a part of the world, then that looks pretty different. And you can keep self-dividing this, right? So if there's a lot of usage in one region, you can keep going down into a city scale

or you can go all the way down into a data center scale. And of course, you can secure. pretty maps to that, right? So definitely in the smaller scales, you're going to be at higher risk, but you're stamping your way up into kind of the consensus hierarchy. I think that's one important component. And this geographical split also gives you partition tolerance, right? So you can imagine one country or one continent losing access to the rest of the internet. And so maybe they can't see or observe all transactions outside of their sphere, but you can still get consistent transactions within that continent or that country or that city.

So I think that blockchain systems have to move into that realm. The other component that I think is really key here is to start sharding in an application-oriented way. So one of the really key things about computing in history has been being able to recognize that a lot of the access patterns to data and computation use case oriented are a specific kind of where a lot of the kind of the reason rights for an application or in important transactions happen, if you start modeling your system to match the application you use, you get a bunch of performance gains.

So I sort of expect that we'll end up having application-specific shards or application domain and industry-specific charts that have different parameter tweaks for those use cases. So certain use cases don't require super-hard consistency right away. They are fine with eventual consistency. And there are other use cases where consistency is super critical, but they don't have to move as fast. is being able to tune your selection there and being able to be on a chart that operates one way versus another

it's kind of like a really, really key piece here. I think the way that this is going to end up playing out is that eventually we're going to split up the consensus protocol part, like linearized ability from all of the smart contract part. And we're going to build one layer that's just around getting linearized ability in this very kind of hierarchical generic way that's super scalable. And then we're going to build systems

that can do the interpretation of what got linearized and the computation of what that output is. That's the second layer. And so I think like that's already starting to happen with the theorem. So the beacon chain is one important step in that direction. You have, you know, one important hierarchy split there where one of the main, the beacon chain is just around maintaining the global consensus security

and not necessarily doing the competition in the charts. But I think it has to go, like, I think this is going to end up getting separated out where many different protocols are going to be homed in one consensus layer. We just haven't figured out where that has to be. Nobody really knows the parameter space yet that is going to succeed there.

But I just think right now, blockchain systems are dramatically way too complicated and they're not going to stand the test of time this way. I think they're going to split. I think they're going to have layers of them ripped up. In the same way that when you think about the TCP IP stack, TCP and IP are, first of all, two different protocols that together are helped by a whole protocol soup, you know, alphabet soup type set of other protocols, many of whom like have

changed a lot over time in history. And a lot of flows that don't even use CCP anymore, use Quick and other kinds of systems. And even when you look at IP itself, it has emerged, changed a lot. lot and has all kinds of like in-between layer-layer things. So I think taking another path of the entire blockchain system with an IETF-style view of decomposition of protocols and really getting at the core problem and building one protocol that solves one problem extremely well, and that's it, is what's going to lead to the

things that are going to stand, you know, many decades and they're going to give us the scalability we need. So like those are like kind of my thoughts on where the block scaleability can go. but yeah, happy to dig into any of those pieces further. Yeah, I mean, thanks so much for joining us, Juan. It was like, you know, so awesome to like catch up and like have this, you know, just the complexity and the richness of everything happening around Filecoin and protocol apps is amazing.

And yeah, I think, you know, we're just at the beginning right now with the blockchain being live for a few months and, you know, people building new applications. So, yeah, we're super excited to see how this is going to play. out and kind of the impact is going to have in the coming years. So thanks so much for joining us. Yeah, thank you so much for having me. It's been really awesome to get to chat about all these topics with you. Really enjoy talking about all these different areas. So really appreciate the chance to do it. And yeah, really fun conversation. Thank you. Thank you for joining us on this week's episode. We release new episodes every week. You can find

and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners,

you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much. look forward to being back next week.