On The Brink with Castle Island - Josh Benaron (Bundlr) on the Importance of Permanent Storage and Provenance (EP.395)

Episode Date: February 6, 2023

In this episode, we were joined by Josh Benaron, founder of Bundlr, a scaling protocol built on top of Arweave. Josh shares his views on: Censorship resistant and permanent storage The importance of provenance in attributing and distributing value Why Arweave's approach to decentralized storage is elegant How Bundlr addresses trade offs in Arweave and makes it more usable Follow Josh Benaron here. Learn more about Bundlr here.

Welcome back to On the Brink. This is Ria, and in this episode, I had the chance to host Josh Beneran, who is the founder of Bunler, a protocol focused on improving transaction volume and speed on R-Weave, a decentralized storage network, and bridging the gap between R-Weave and other crypto networks and applications. In this episode, Josh goes over the rationale behind censorship-resistant and permanent data storage. The importance of provenance in facilitating accurate attribution and fair distribution of value, why RWeave's approach to decentralized storage is novel and elegant, and how Bunler specifically addresses tradeoffs in Rweaves' design and augments the decentralized storage network. So without further delay, here's my conversation with Josh. Hi everyone, this is Ria from Castle Island. Today I'm joined by Josh Beneran, who is the co-founder of Bundler Network, which is a project that is seeking to improve transaction volume and bridge the gap between R-Weave and other blockchains, seeking to scale and optimize R-Weave, which is a decentralized and permanent storage network.

I think this is the first time that we're actually talking about R-Weave or. Bundler in depth on the podcast. So we'll get into what all of that means. But before we kick it off, Josh, can you give us a quick intro on yourself? What were you doing before Bundler? And what inspired you to build Bunler? Yeah, good, good questions. First of all, thank you for having me. But and yeah, just to provide some basic history of me, it's maybe not the most exciting story. I haven't been in crypto for 20 years. I'm not one of the OGs. But I kind of got into crypto about three years ago when I was at school, at least very lightly. And then when I went to university, I was studying computer science in the UK. I kind of got very deep into crypto at the kind of the

start of COVID, kind of around that period of time. You know, I had nothing to really do. So I was just kind of focusing and learning about crypto. And yeah, really I was I was always looking for a way out of out of my degree in computer science. So I ended up discovering, discovering, are we just through research, looking to the storage kind of storage protocols. I went through the usual kind of journey of IPFS, Falcoyne, CR, storage, and then I discovered RWeave. And when I found Arweave, I kind of fell in love both with the ecosystem and the developers. And also I became good friends with sound.

I really actually can get more into this, but I also very much fell in love with the design of the protocol itself, which is fairly elegant. And yes, so that was kind of fair, February time of 2021 that I discovered RWeave and started building Bundler around April time after some conversations with Sam, who's the founder of RWeave, around kind of scaling problems that Rweave is going to be hitting. And Bundler was initially really focused on solving those fundamental scaling issues. How did you kind of develop the skills set and expertise beyond just studying

crypto for a couple of years to start building something like Bunler. It's very hard to pinpoint kind of what is the one thing which made you really good at what you do or really enjoy what you do. And what I'll say is that I kind of really got into computer science programming when I was about 15 or 16. So actually fairly late compared to other people in computer science. And one thing is having that foundation of just spending a lot of time doing that thing, doing a very computer science-based things for four years.

it was that's kind of a good foundation. And then I'd say that the final thing, at least the big thing which got me to the point of understanding of where I am now, is that I have worked with some of, I would argue some of the best people in the space, some of the best people in the space is what I'd say. I'm going to show Sam Williams, again, founder of Rweave.

I really worked with him very closely from about February time and almost worked with them daily for about six to eight months, which it's quite cool to work with someone who is the founder of a fairly kind of fairly large protocol every day solving lots of key problems and you know i literally there were days when i would work with him for eight for kind of six to eight hours uh and we were solving lots of problems i have all kind of stories about when we were shipping bundler amongst other things and yeah you can kind of most of my learning when it comes to the crypto came actually a lot of it came from sam or at least working through problems with Sam.

So I think between the foundational knowledge of understanding computer science and programming, et cetera, plus working with someone who, once you get stuck in these problems, you can go to them be like, like, how do you solve X, Y, Z? And then provide you like the foundational answers of why things are. I think if you really have that foundational, ability to learn the foundational knowledge, it really kind of set me up for the success in that sense. That's amazing. Yeah, I'm sure it really accelerated.

your journey relative to some others that kind of go on the journey on their own. You know, you mentioned a number of other file storage protocols and the fact that you found R-Weave's design in particular to be relatively elegant. Can you just at a really high level tell us what R-Weave is, how it works, and how it relates to some of the other protocols you mentioned? Sure. So I don't know if I think it's probably easier to go the other way around and actually start with the other storage protocols because I think it's easier to go from kind of understanding of storage as we know it and then kind of going up to our week, we would say is the biggest step. So storage as we know is kind of the AWS just kind of cloud storage that we know if you store something on Dropbox that's using probably using something like AWS or Amazon in the background to store the data. So that's a very centralized entity. And then kind of came along the IPFSs and file coin, which, you know, which is both built by protocol labs, which is essentially decentralized temporary storage. So the idea is that, you know, you know, storing something at AWS is temporary.

You have to pay monthly fees. Filecoin is similar in the sense that it's temporary. You pay for an amount of storage for a period of time. It's not a permanent form of storage. It's just kind of similar, similar to kind of what AWS is, but decentralized. And then there's also kind of storage and COE, which is you can kind of look them as similar to Filecoin, in the sense that there's temporary storage. So again, all very similar.

And then when it comes into R-Weave, it's actually a much different design and a much different set of goals and different problem space, which is what R-Weave is, is a permanent storage protocol. So unlike, you know, AWS, which is centralized or file coin storage, etc.,

which are the temporary storage ones, R-Weave is permanent. So you pay once and it's stored forever. That's the idea. There's no recurring fees. And that's going to be, the promise of, promise of,

in 10 words, it's kind of, store, pay once and store forever. That's pretty much it. And I guess they kind of get deep into, deep into why, or why and how,

but the kind of properties of permanent storage is that you can build this perfectly censorship-resistant system. Censorship comes from the fact that things disappear. And that could be in the forms of deletion, updating deletion, etc, etc. So blockchains inherently are immutable. They stop the updating of data.

And they also stop the deletion as well. But they stop the updating and the deletion. But when it comes to the storage, you need a new foundational set of incentives to kind of really make things permanent and censorship resistant. And the promise of Aweev is to bring in perfect censorship resistance, the kind of final aspect of what these other blockchains

promise. But yeah, the general idea is, that you pay one store forever and it's totally censorship resistant. Maybe just taking a step back and talking about, I think maybe it'll be helpful for listeners to, from your perspective here, what are some of the issues that have been created by this temporary storage model that proliferate in Web 2? Any form of, I guess this is more of a question of why this question fundamentally boils down to why decentralization actually, which is when you're looking at the data layer of a lot of these systems, why does decentralization and permanence make a big difference or where has it failed in the past? And you can kind of look at any form of censorship as a form of data censorship. If, for example, going down the very political spectrum, political side of things, it's like, okay, if a specific journalist that the article is all deleted,

then that is very much a data problem because if the data lay itself was sensitive, decentralized and permanent, then no one can do that. No one can really shut down people's voices. Arewe provides the right to have a voice? That's really, that's kind of really what are we've does. And just to provide an example, there was a paper in in Hong Kong. It's a fairly well-known paper, and I forgot all that was called. But the point is that there was a paper in in Hong Kong which during the whole Hong Kong issues which were two years ago now with when China was trying or is still trying to take Hong Kong and they shut down all of the papers basically and they ended up archiving all of their papers on our weave

such that China could could not censor that data and I guess just to kind of expand on that if you look at all forms of tyranny, authoritarianism, it's always come down to controlling the flow of data, controlling the flow of information. Like if there was a book on how to become an authoritarian, I'm sure there's maybe there's a book out there. The first step would be control the data, control the news.

It really comes down to the data layer. So when it comes to the censorship, it's fundamentally, if your data layer is compromised, then your whole system is compromised. that's the way to look at it and that's the way that always looks in the sense that if you solve the data layer, you've already solved 90% of your censorship problems. I think one natural question that emerges from that specific use case, and I'm going to hop around a little bit here, but is this question of incentivization? So who is incentivized

to actually pay for the storage of this data? which maybe you can think of as like a public good, right? So in that specific use case of, I think it was, was it Hong Kong's Apple Daily? Was that the publication? Yes, yes, that was it. I knew it was a very large one, sorry. Yeah, I remember reading about that.

You know, in that situation, who took on the burden of actually paying for that data storage? And how do you see that changing in the future? That's a really good question. And yeah, that's a really good question. In that instance, I guess they were incentivized to do so from a kind of value standpoint. They are willing to front the cost of that for the value standpoint. But I don't think that's the most interesting use case when it comes to RWeave and that question specifically.

I think it becomes very interesting when we look at something like creators and paying for their data, which is, I know a big pivot. But it's kind of another use case of Rweave, which is a lot of the decentralized creator. related things like it's essential as YouTube, TikTok, etc., etc. You see this a lot on the lens protocol side of things. And it's a good question and the answer is as creators, at least from a creative perspective, as creators make more money, there will be more incentive to use a more resilient data layer. And the idea is that Web3 is really allowing people to own their data. And what that really means ownership really means two things, which is that yes, they control it, but two, they can monetize it.

They're the people that can fully monetize it. That's really what it comes down to. So fundamentally, you need a censorship and permanent layer in order to have a monetary layer as well because fundamentally those two things are tightly linked. So kind of tying back to the question, Apple Daily, they were incentivized to pay for it because perhaps it's in their value system, but that's obviously not a very scalable system. In the future, I expect creators will pay for it because the money they'll be making is will probably be far greater than it is now, at least for the bottom 50% of creators.

I think that they are the least looked after by the bigger tech companies like YouTube. And very much as those monetary protocols are built into things like Lens, etc. you will be able to, there'll be more affordability with the storage as well and it will become very, very important. And you kind of see this, right? You know, Lens Tube is using us and a bunch of other video platforms using us. A lot of creator platforms are choosing Rweave because fundamentally having permanent storage gives control to the creator and safety to the creator. And we can both list tons of, you know, tons of people who have been wrecked by creator platforms like YouTube. I can list tens.

And I'm not even that deep into the creator world. So it kind of speaks volumes. I want to keep pulling at that thread of how powerful this primitive and protocol is for the creator economy. And, you know, you talked about it in the context of having permanence and some level of guarantees around content. They create data. they create. And I think another really powerful capability maybe that this enables that, you know, I've seen you talk about David Phelps, shout out David, that's talked about this a lot as well, is, you know, we're moving or are in an era of user generated content

and remixing. And today, you know, that's well, and good for maybe increasing distribution and awareness of creators, but actual value capture isn't really there yet. Can you talk about how something like the combination of bundler and RWeave enables that? Yeah, sure. I mean, there's lots of things that come into value capture. Most of it, most of it comes down to protocolization of each layer, essentially. And it's kind of comes down, comes down to what I'm saying. It's like YouTube system is actually very complex. There are kind of five layers to it, let's say. One of the lowest level is the storage, but the levels above that as well, including the money, the how people are paid as a protocol as well. It's protocol controlled by

YouTube. So, I mean, it kind of reiterating what I said before, one part of it is protocolizing the payment, the payment side of things, which could be automated with smart contracts and things like that. But tying into, RU even and bundler and tying into the question, it's really around provenance. And what provenance really means is knowing basic things about the origin of that. It's about knowing basic things about the origin. That's the dictionary definition. But what that really means in practice is, okay, Ria goes and kind of creates some content. How does she prove that she creates that content and not David Phelps? Like, how do we, how do we prove that? And fundamentally that comes down to lots of different things. And there's also the idea of when

was it created? Did you create it before? Did you just copy it and then claim it? Did David Phelps actually create it and you copied him? There are lots of open questions in terms of how do you solve these problems in the decentralized world while making sure that people who are actually doing the work and making the money. The whole idea behind Web 3, if you look at any system is okay, the more work you do, the more value you provide for a group of people, the more money you make. It's a very kind of, it's a very bad definition. But the generalizing, is it's the same, right? It's like if you look at Bitcoin, it's like the more value adds to the network, the more you're mining, the more value you're adding to the network,

then the better the thing is. And the value in that sense is security. So the more security. And same with proof of stake. It's like, okay, the bigger the stake, the bigger the reward, because you're providing more security for the network. So that's the computer science perspective. But looking at it from just the social perspective, it's like, okay, if I'm creating content that a billion people watch, well, I probably deserve to be paid for that. And I don't want you to be paid for something that I created. That's obviously not very smart. So it's a very big question of how do we prove the provenance of these things as well?

And one of the things bundler is looking very closely at and it ties into our web as well is how do you, how do you prove that provenance piece? And for me, that comes down to two things. One is when when was something created and who created that thing. And then there's a third step as well, which comes to remixes. But if you're looking at the base content, Bundler really provides two things, and we inherit this from Arweave as well. So Bundler actually provides accurate time stamping on data. So the idea is that if you upload some data to Bundler, you'll get an instant time stamp back of exactly when it happened to the milliseconds. So you have this very accurate way of measuring when something happened.

So just to provide context on perhaps if you use the Solana, for example, the time resolution for Solano is 500 milliseconds, the block time. for for r weave it's two minutes so every two minutes you get time stamp so it's not as accurate but bundler provides a real time timestamp so it can essentially build these real time provenance chains where we say okay rea created content i clipped it david created a remix of my clip etc etc and then you can kind of build this provenance chain of kind of who did what at what time and you can kind of see hopefully i'm drawing a picture which can conceptualize it which is that you can essentially drive where the money's going based on this provenance chain. And the other thing is that, at least from a kind of feature standpoint,

Bundler, one provides the time stamping, but you're also allowed to label data in multiple ways as well. So if you want to prove that it's you, you can easily add kind of labels, which essentially allow the data to be queryable and searchable. So it's a very kind of, at least from a developer perspective, it's very cool. And the final thing, which I have to say Bundler doesn't solve, but I have had a lot of talks about recently, which is that with this kind of topic being very important and provenance becoming a very kind of big topic,

apparently for the last month or so, I think zero knowledge is going to be a big part of this as well, which is that, okay, if I have clipped a video, if I've cropped a video, how do I prove that I've cropped a video? So that's actually a very difficult computer. science problem, which is like, how do you actually prove that this clip came from this other video? It's actually really difficult to solve.

And the idea is that, you know, within that, I would argue, in the next five to ten years, we'll have pretty scalable solutions, which allow you to do that. So you'll be able to mathematically prove that David clips something that I created that you originally created at the beginning. And then, yeah, at the point we have mathematical proofs of these things, then you've built a very decentralized system, which allows you to flow the, the money in a really even way. Like imagine,

imagine on TikTok if I created a video and then everyone on YouTube and everyone start clipping it and putting it on TikTok. So if I created a video on YouTube and then you start clipping it, putting it on TikTok, well, I'd argue you deserve some of that revenue share because you're distributing my content. And you can only really do that when you have things like the mathematical, like the accurate timestamping and the provenance that Bundler provides plus the

permanent. And then you add the proofs to it. And then you have this give or take a few gaps in the same. solution, you basically have a full solution of proving who did what. And then you can build this amazing monetization process on top of this, fully decentralized, such that everyone who distributes your content and is the best that distributing content, you get a share of the revenue as well. And I think we're probably, for that final, final really good solution, I'd say we're

probably 10 years away. But the optimist to me would like to say we're five years away. But that kind of ties into how bundle are solving things. And then also how it will tie into a future. as well in flashed in this time. Yeah, I appreciate you kind of identifying some of the gaps to actually, to actually getting to that point. I want to take a step back and talk about what exactly Bunler does for R-Weave and maybe

some of the, the problems that it solves for R-Weave. And you mentioned one of them as you were talking, which is, you know, this, this difference in block time and the ability for Bunler to kind of provide real time provenance and guarantees. But talk a little bit more about, you know, as you were working with Sam before Bunler was live, before you came up with the idea for Bunler, what were some of the maybe tradeoffs that Arweuf was making that you felt like you could solve with Bunler and that you are solving today with Bunler? Firstly, Arweev is a great protocol, which really focuses on doing a few things really, really well, which is actually

is a good way of designing computer science systems as a whole. And what Areweb is very good at is storing large amounts of data permanently. That's pretty much kind of in a really basic way, how to describe things. And I'll come to some of the trade-offs there. But the idea is that the limit for Are Weif, when it comes to storing data, is it can store two to the power of 256 bytes per two minutes, which is, by the way, that's basically per block, it can store more data than exists on this entire on this entire planet. So there's no real fundamental limit to the amount of data that can be stored. And there's comparing us to something like Ethereum, it's like it's, you know,

Ethereum, a megabyte costs thousands of dollars and Rweev, it costs a cent or less than a cent, actually, a thousandth of a cent. And yeah, it's kind of a huge, huge difference. But kind of tying into the tradeoffs there, well, Alive has the same kind of tradeoffs that's something like Bitcoin has, which is, okay, what if a billion people want to use R-Web at the same time? Or let's use Bitcoin. If a billion people want to use Bitcoin at the same time, well, you're going to run out block space.

And same with the theory, right? You run out block space. And the same thing kind of happens. When the demand well exceeds the supply and the supply being blocked space in number of transactions, then the cost of doing this said transactions is much higher. So just before Bundler launched, I mean like two weeks before Bundler launched, always block space was totally full. So there were basically, there were times when they were like 100,000 transactions within a minute

because there are lots of people dropping NFTs and stuff like that, obviously. And fees would go up 100x. So when you're paying, you know, $1 a gigabyte, you were suddenly paying $100. And that's just kind of the basics of a blockchain fee market. But that kind of explains some of the tradeoffs that happened. when you have the system that can store lots of data, but only a certain number of transactions within a minute. And kind of tying into Bundler,

the thing I used to say is, okay, always can only do 30,000 transactions an hour, it's not that many, how do we scale this to 30,000 transactions a second? That was always the, that was always the kind of the initial vision anyways. And recently we scaled up to 50,000, I don't know if you saw it a week ago. But, yeah, so we kind of hit that goal as well.

But that was kind of the original trade-off with R-Weave and also what are weave, what bundle of tries to solve. I guess the final thing is that to use R-weave, you need R. Like, that's kind of perhaps an obvious one, but acquiring R can be sometimes a little bit difficult. And also, if you're building a system on multiple chains, then do you want to have to have two tokens, like amatic tokens and R-tokens? Do you want users to have both those tokens? There's lots of design space issues there. And, yeah, Bundler looks to solve a lot of these problems. Can you talk a little bit about how exactly you do that?

You know, how have you structured Bunler to scale R-Weave? And also, you know, I think one of the biggest value propositions is to kind of serve as a bridge between other chains and R-Weave by kind of not requiring them to have to pay in R-Weave's native token. So yeah, talk a little bit about how you actually enable that. Yeah, sure. So to kind of summarize bundler in three ways, we very much focus on speed, scalability, and multi-chain.

And now I'll kind of tie into it. So speed being how quickly can you upload? So with RWE, you have to wait 10, 20 minutes for something to be confirmed, essentially, or confirmed to a high enough degree. On bundler, it's pretty much instant. It's less than 100 milliseconds. And then scalability is like, okay, how many people can I, have on this system at one point in time, which comes down to the transactions per second.

And the final one is, okay, how do you let people use other tokens to buy or use permanent storage essentially and use bundler slash Rave? Those are the three problems we solve. So looking at the design, whenever I explain to people who don't necessarily know as much about Rave, I always like to compare us to optimistic roll-ups, which is a scaling solution on the theorem. But the idea is that you take a bunch of layer two transactions, you stick them all together and you dump that as a single layer one transaction on on our weave. And the idea is that, okay, if you can batch a million transactions in a single layer one transaction on our weave,

and there are a thousand transactions in a block, simple maths, a thousand times by a million, which is a million per transaction, you've got a billion transactions per block. So every two minutes, you can have a billion transactions. And that's the, that's the very basic way, of how bundler scales. It's actually the way that you scale all. Blockchains is always some form of roll-up. It's a way of batching a bunch of transactions together. It's how the Lightning Network works.

It's how Ethereum roll-ups work. It all uses that to some degree. The reason why I say it's like an optimistic roll-up is more about the fact that we dump all of the data on the base chain. So we dump the entire state on chain. And the reason that's important is because that means it's fully decentralized. there's no state stored off-chain.

Anyone can verify that bundler is being honest. That's kind of the key part there in kind of maintaining some degree of decentralization at this stage. So that's kind of the scalability part. And then from a speed perspective, we very much kind of optimize speed and we have to kind of make the heuristic decision that kind of something like,

I don't need to be polygon, polygon to side chain. Let's say something like optimism or, okay, Zika's thinking, this is, this is, I'm getting into a debate here, but no, I, I meant more, in terms of scaling things like speed, we use kind of centralization vectors, sequence are kind of models such that you can essentially handle any number of transactions. But the cool thing is that with bundler, it's more for non-financial use cases. And the key thing there is that you don't need to have any shared state. So fundamentally, when you're using something like arbitrarum, optimism, etc, you're still limited by the fact that everything kind of needs to know about everything else

and it's like imagine if you're in a crowd of 100 people and before taking a single step you have to ask 100 other people is this okay like that's kind of maybe a crude example but that's kind of how that's kind of how blockchains work and that's how also l2s work but the thing with with bundler is that there is no shared state so you inherently can kind of scale bundler infinitely and what we kind of say is that we can theoretically scale bundler to millions of transactions per second if we needed to. And that's super cool. And there's no kind of increase in fees as well.

So it's a very different design to the Ethereum L2s. And then I guess the final thing, which is the multi-chain side of things, which is actually kind of a cool innovation that we did, which was essentially the transactions on bundler are these kind of cool binary formats, which allow you to sign it with different keys. So when we actually integrate tokens, we're actually integrating the actual cryptography of each chain. So when we integrated Solana, we actually integrated this cryptography curve known as ED-25519, like the specific curve that Solana uses. And then that inherently means that we can use kind of Salana keys to sign.

So you don't even need an R-Web key at all. You just need your Salana key. You need some Salana, sign the transaction, pay for it, and you're done. You don't even really need to know you using R-We. That's kind of the key thing here. You're abstracting all of this away and it just feels like you're using salama. So that's kind of the high level of how this works. Going back to, you know, your second point around batching transactions and then settling them to the R-Weave, let's call it L1, if we're, you know, continuing using this analogy of Bunler as an L-2,

talk a little bit about like the guarantees that users or Bunler are getting when they're using Bunler and how you kind of enforce those guarantees. Sure. So there are firstly there are guarantees that we inherit from Arweave. So the basic guarantees around retrievability. So there's this concept of, I won't go too deep into this, but there's a concept of availability and retrievability. So Bunder, sorry, RWev provides guarantees on retrievability, which is that like,

okay, in a hundred years time, you're going to be able to retrieve this data. That's kind of the guarantee. So there's that kind of guarantee that RWeve provides. And then for Bundler, it's really about providing guarantees around the time that it takes to get on chain. So Bundler, it takes about up to an hour for data to settle on. So I use the term to settle, just use friendly terms, but to get on to Arweave. And it's really about providing guarantees such that you know that within an hour, your data will be on chain. That's kind of the idea.

And the way that really works is we have this kind of receipt system, which is that you post the transaction to the network and you get this receipt, which is essentially proof that you've uploaded this transaction, and it has this block cutoff point, which is basically a deadline saying that, okay, if this transaction is not on, not on Rwe, not on L1, buy this block, then the node on the network and get slashed. So imagine that it's,

100 blocks. Each block is two minutes. So it's 200 minutes. If the block cutoff point is in 200 minutes and they don't get the data onto ARWIV within that 200 minutes, then their stake is slashed. That's kind of the design that we go for within bundler. And then do you also provide some kind of redundancy guarantees? For AWI, I guess to go deeper into what permanent means. Permanent inherently means redundancy. So to make something permanent, you essentially need to provide the incentives to store things for long periods of time in several different locations redundantly. That's kind of the definition. That's the very non-fluid definition of permanent. So, Always provides guarantees on retrievability by providing this kind of concept of permanence.

And kind of going, kind of double-clicking on that a little bit. The idea is that, are we provides very, strong incentives around miners storing data, such that the replication rate of the network is currently it's 45 plus. So there are 45 copies of your data stored on the network. It's being reduced to 15 because 45 is, I can tell you now 45 is too much. A lot of research says that beyond 10, it's, it's kind of pointless. So it's kind of being reduced to 15. But the idea is that if you provide strong enough incentives such that a group of random people want to store your data and there's at least 15 random people who want to store your data for the next hundred years, then you'll be okay. This is kind of the definition, this is the very kind of trim down definition of

what permanent means and also kind of ties into those guarantees that you get as well. And today on Bundler, who is actually conducting the bundling or the batching of transactions? The whole network is currently operated by us. We are very transparent about this. We try to be. So, yeah, the current state of things is that we're fairly centralised by in practice. In terms of kind of where we are, we're planning on decentralising. And I, if not to shoot myself on the foot, but we plan to do this sometime next year.

And we hope to have a test net by the end of this year as well. So it's kind of a key focus. It is a very, it's probably our second highest priority right now beyond just kind of building things, which are useful. So we are very focused on decentralization. And tying back to what I said, it's like, fine, if we believe this data layer needs to be decentralized, well, we're just kind of incriminating ourselves by saying that, okay, we're totally centralized. So what's really the point there? So, I mean, yeah, maybe talk a little bit about the path. I don't know how much, you know, how far along you are in designing the decentralized version of Bunler.

But what does that look like? What would the requirements be? I don't know. Maybe that's a question that you're still answering. But yeah, what would the requirements be to be an entity that batches transactions on the network? It's a good question. When token? No, but no, all seriousness.

I don't want to share any half-baked thoughts is kind of what I try to avoid. But we do have lots of different designs. And really when you're looking at designing a decentralized system, it's like, okay, one is like what services do you want your network to provide? Because you look at like basically all networks and all blockchains are services. They're service provisioning things. So Ethereum provides, I mean, I would argue Ethereum provides a service of consensus. That's really all it does, all it does.

And we value that, you know, at $100 billion plus. Like we think this social consensus is extremely powerful. And the idea behind our weave is, okay, the service is permanent storage. And you could also argue the service is kind of this right to speak. And when it comes to Bungler, it's, okay, the service we're providing is kind of a few things. One is the kind of the scaling of storage. It's the arbitrary kind of scaling of storage. two is that kind of guarantees on time,

the very high resolution time stamping system that's built into bundler. And then the third one is we have some data availability guarantee. We have some data availability guarantees as well. So those are kind of the three services that we kind of look at from a network standpoint. And then after that, it's really about deciding on where on the spectrum of decentralization do you want to sit?

what consensus protocol do you want? And just to kind of show you the two sides of the spectrum, there is Binance chain, which is basically run by Binance. And it is right, not basically, it is run by Binance. And yeah,

and the most essentialized being something, I would argue like Ethereum. ETHMexio there. And then there's kind of things in between. There's Arbitra Nova, which is kind of on the, the Binance side. And then there's kind of the,

I don't know what else is kind of, on the side. But it's kind of, you get the idea that's a spectrum and really where we need, when you're designing a decentralized system, you need to decide where you're still on that spectrum and that decision isn't major. In general, it's going to be some form of Oracle system. It's like there's going to have to be some form of chain verification of things, which is really just an Oracle system. But beyond that, we, yeah, no details to share quite yet. You'll be the first to know. Great. I'm excited. So I want to talk a little bit about, adoption of both Bunler and Arweave. Talk about, you know, when did Bunler go live? What portion of

activity on Arweave is flowing through or directed through Bunler today? We launched around, I actually don't know the exact day. I should know this, but we launched around July, August time in, uh, in 2021, kind of the half, I remember the heart of COVID. Yeah, so we launched around that time. And we actually launched with Metaplex, which is Solana's, like Salana's NFT infrastructure, which is kind of where the boom, the boom began. And at the time, we were doing a large volume. I mean, we were doing in the 90s of, we were definitely doing some 90-something percent of the transaction volume. And I think to this day, we are still doing it. I mean, right now we're doing two million, well, 1.7 to 2 million transactions a day at the moment. And I think that accounts

for a majority of these transactions, I think above 90%. So seem to have still a fairly large percentage right now. Are there any use cases where a transaction would have to flow directly through R-Weave and not through Bunler, or is it always better to just flow through Bunler? There are trade-offs, is what I'll say. So when you're working with Arweave, you have to eat up, eat the fact. You have to deal with the fact that

you will have to wait for things to be confirmed if you want to build a highly resilient system. You need to use our tokens. It's not that big a deal. And you also need to need to go through this process known as seeding, which is this idea of getting the data onto the network. So there's data, there's transaction confirmation.

And then on Arweave, there's this concept of transaction seeding, which is like, okay, how do I get a few miners to store my data? Like, how do I get them to store my data straight away? Bundler provides guarantees on seeding. It's not something we talk about too widely because this is very kind of technical topic, but it's generally we provide guarantees that data get stored in the network very quickly and very efficiently. So you kind of have to deal with some of the lack of guarantees there when using the base chain because you have to go through services which don't provide those guarantees. But I guess kind of playing devil advocate on bundler. Bundler is very much optimized for smaller transactions,

only because the way, one of the cool properties of bundler is that if you're paying for a transaction, which is below 200 kb, kilobytes, it's cheaper on bundler than on our weave. It's, it's much cheaper actually. So there is actually this, this pretty, like the most interesting use cases of ones like desocial, etc. where it's like lots of small, transactions for bundler. And there's an argument, if you're going to go ahead and store a petabyte tomorrow, which is a thousand terabytes tomorrow, you might want to use the base chain. It would be cheaper, but you would also lose a bunch of guarantees that bundler provides. You'd lose instant retrievability. You'd lose the guarantees on guarantees on seeding.

You would lose guarantees on confirmation. You have to wait 10, 20 minutes to be sure. Like you can't build real-time systems. And most systems are real-time. Like, In some ways, all systems require instant feedback. So there are trade-offs. It's not me saying that you wouldn't, but there are pros and cons. And would you say that Bunler has been like specifically architected for R-Weave, the decentralized permanent storage network? And at this point and maybe forever is like inextricably linked to R-Weave?

or would you foresee a need for something like Bundler on other decentralized storage networks? Yeah, I mean, I don't want to talk negatively about other storage networks, but my general view is that... I mean, you're opinionated, yeah. I have opinions, but I'm not sure if I should share them. It's a very big difference. But yeah, so right now, the architecture, there are specific nuances. This concept of seeding is obviously a very R-Web specific thing. There are parts of the system which are very kind of nuanced.

But the idea of something like bundling at a much higher level is something you need for something like Filecoin. So just to provide basics on Filecoin, the way it works is you kind of have to buy 32-gibite sectors. I forgot what they're called, but basically you need to buy 32-gigabyte kind of chunks. And if you want to efficiently pay for storage on Filecoin, you need to pack data together. So if you've got like if you've got 100 gigabytes of storage, you need to essentially pack or split that into three efficiently packed or I guess four efficiently packed sections. And that's just how farquit works. And you kind of see how bundler fits into that.

It's kind of this way of automating that that batching of transactions such that it would automatically fit into these 32 gigabyte chunks. That's a theoretical design. What I will say is that frankly, we're not very, we're not, we're not, we're not, we're not focused on other storage protocols. At least right now, it's not, it's absolutely not a priority whatsoever. There are lots of,

we truly believe that permanent storage is the way the world is going to go. It's where the creator economy is going. It's where social is going. And I think it's, I think it's going to be used. Within the next 10 years, I think Rweev is, from a storage volume perspective,

no token speculation, it's going to be a thousand X or more from a storage perspective. like no doubts, a thousand, I'd probably say more. I'd say in the 10th of thousands. And I have absolutely no doubts of that. So we're very much focused on RWEVE and driving a lot of the values we kind of have with RWEV because fundamentally we're also a very value-driven company, we're a protocol, but also the company that develops this protocol, we are very value-driven.

And fundamentally, we truly believe that R-Weave is the most decentralized and censorship-resistant data layer out there. and it's where most data should be, at least most censor prone and data should go for things like NFTs, etc. Given, you know, in your view, and I think a lot of people share this view as well, given that our weave is so elegantly designed and, you know, offers guarantees that have never been available before, why is activity on RWEV? we've relatively lower compared to a system such as file coin that seems to have, you know,

the greatest market share of decentralized storage protocols today. I've actually gone very deep into this topic recently in the last kind of probably two months. And okay, one question is how, and this is more of a rhetorical question, but like, how do you look at what is the most popular thing? Right. Perhaps one question. and there are two ways to look at it. Are we looking at the right metrics?

Yeah. Yeah. I mean, one thing, like my opinion is you look at demand side revenue. That's kind of my, that's kind of my view of the world. And even by that metric, we're not as, it's not as big as something that Filecoin. But what I will say is that our weave is a new use case. And so this is no, this is like, I know people at Protocol Labs, the great people, I'm not saying anything negative about about Protocol Labs. But what Filecoin really is, is what we already know, it's temporary storage at a fraction of the price.

So they're really just selling something that already exists at a fraction of the price. And you can kind of see how, okay, it's much easier to onboard a bunch of storage doing that. When you build a fundamental new technology, the curve is much slower, at least at the start. It's going to be much, much slower. And Filecoin, it might be like that because it's just it's a cheaper version of what it exists. R-Weave is a totally new use case, which also is solving new problems. And it's not just looking at the old problems and applying R-Wev to it. It's also a key, like, what are the new technologies which R-Weave enables?

Whereas Filecoin, from a storage perspective, temporary storage perspective, they can just kind of sell to the old market. So from a business perspective, you can kind of see the difference. and yeah so it's a valid question and I do think demand side revenue is important I think it matters that people on the network are highly incentivized what I will say is that devil's advocate to people saying that the revenue on our weave isn't very good is that okay it might not be that good right now but our mind is on the network incentivized yes so there's no there's no real need to complain in that sense at least yeah at least from a kind of what are

Eve is trying to solve, it's solving what it's trying to solve because it's incentivizing people on the network to do what the network is meant to do. So great. Yeah, there are absolutely valid arguments on both sides. I'm personally not worried only because, like, I think the revenue will increase over time. Yeah. What about from a, I think that makes sense. You know, it's easier to grasp something that is doing a decentralized version of what already exists today, much harder to Maybe also, and maybe you can speak to this from a cost perspective, you know, the upfront cost of using something like, and maybe the business model is similar to using some of these temporary decentralized storage networks relative to something like Are Weave where the upfront cost is higher if I'm interpreting it correctly. When you use something like Filecoin, you work with a more centralized provider, which, provides this kind of subscription model usually for storing data.

And that's a very typical model. People are very used to this. People use S3, these usage-based models for a long time. And then R-Weave, it's very different. One is a totally different service. It's again, that service I do, it's permanent storage, which means the use cases don't kind of, they don't overlap as much as people think.

And it's not one or one. Yeah, it's not even close to one-to-one. Yeah. from a cost perspective, yeah, it's kind of strange to people. And I actually understand it's like, okay, one is like, why am I paying for 200 years, like 100 plus years of storage, permanent storage? And also, why am I paying up front now? Why do I have to, like on S3, I don't have to pay for the next 100 years on S3.

Why would I do that? And it's really about, again, it's about trade-offs. It's, S3 doesn't provide you the guarantees that always provides you. That doesn't provide the guarantees that file going to provide you. They all have trade-offs. And fundamentally, I think it's not about like, oh, Filecoin versus Rwe versus S3, although I think S3 versus Rwe is an interesting conversation. But nonetheless, it's not Rwee versus Filecoin, etc.

It's that they all service different use cases. Like there is a use case for temporary storage. There is use case for permanent storage. And they don't always overlap. Arweev just provides very different values that are very different services than other people. And maybe going back to one thing that you were talking about at the beginning of the conversation is this, and maybe we haven't solved, you know, the incentivization of doing this, the incentivization piece of doing this, but, you know, are we actually serving

as a permanent archive for like all data created on the internet, right? That's something that's uniquely enabled by something like, are we? Yeah, and I guess the way to kind of think about this is this. our depiction of history has always been dependent on the stuff that we can find. It's always been a probabilistic kind of a low probabilistic guess on what is happening. And I'm not here to fight historians, but my point is that going forward, in 200 years time, for the first time ever, we're going to have 100% clarity in what was happening 200 years prior or now because we have protocols like Arweave storing this data permanently, providing these guarantees. So for the first time ever, we're going to have guarantees on history, or at least we'll have as much information as possible to provide those guarantees or get as close to those guarantees as possible to avoid semantics and pedanticness as well.

So kind of tying into the internet thing, yeah. So like you could archive the entire internet tomorrow on our even. People in 200 years time will be able to view it and be able to draw a picture of history. And just to kind of show a project which uses bundler but isn't bundler, There's something called the Alex archive on, on our weave, which is essentially this idea of how do you incentivize people to archive things. And the idea is that you archive some information and then you essentially own a percentage of the assets that are created by that. And everything is turned into some form of collectible in some form. And then imagine if you are, I know, this may be a bad example.

If you're archiving, this is a bad example, the Torah or something. Because I've spoken to someone about this. And like, okay, a million people. put in a million dollars and then someone kind of got a specific page of the Torah. I was like, okay, like I own a percentage of places. I don't know if you use a religious book as an example. But still, you can kind of understand how you can build these core incentive mechanisms to really incentivize the archiving of this kind of data as well.

So it's a super interesting use case. Yeah, you just answered the question that I had in the beginning. So we came full circle. Well, before we end the conversation, I do want to, to talk maybe a little bit more directly about some of the use cases of Bunler and what people have really been using Bunler for. You mentioned NFTs, you mentioned L-1s like Solana, talk about maybe the, if you have line of sight into this, the breakdown of activity across different categories of projects

that are using Bundler today. You also talk about social. So yeah, talk about all of that. Yeah, I mean, again, it's like how do you break it down? We break it down in two ways. One is storage volume and one is transaction volume. It's like not every transaction is the same. Some are big, some are small.

I remember I saw someone on Twitter saying that. But yeah, the idea is that it depends on how you measure it. So from a transaction volume standpoint, it's much easier for us to measure. And right now, it's a... It's actually a real mixture of use cases. We have a large percentage, maybe it's something between like 20 to 30% is archiving. We have a large Oracle users,

oracle users storing a lot of the Oracle data, which is probably another 20%, NFTs is still a large percent. It's probably about 20%. And then the rest is kind of hard to identify. Like categorizing decentralized transactions is a really difficult data science problem. So that's kind of the use case.

But tying more into more interesting use cases and where I see bundle going as well is I think for that really high throughput low latency protocols and that's like desocial messaging protocols like the push protocols of the world, etc. When these when these when these adapts eventually decentralize, permanence is going to have to be required to have to build these systems. I think Lens is really leading with that kind of message and permanence is required. for censorship resistance and ownership. And if you need low latency in a decentralized way and permanent, then this is kind of where bundler comes in. So I expected them next two years. If I was to guess where bundler is going, I think a lot of volume will come from messaging

like protocols like social, push, X and TP, etc. Playing devil's advocate from the user's perspective, you know, what if I don't want permanent storage of all of my interactions on social networks? two arguments. One is fine, use temporary. The other one is people look at permanent stories as this really scary thing. And what people don't realize is that if you went and posted a video on YouTube, that date is permanent. Believe it or not. And the reason I say that is because if you're famous enough, someone's, someone's downloaded that, not even if you're famous enough, someone has downloaded it. There are crawlers. There are people downloading these things

instantly. Like the stuff is the stuff exists somewhere. So it's still permanent. The thing that YouTube does when it's when it, when it removes videos is it stops distribution. Like it stops the thing being shared. That's really what they're doing. It's not stopping existing.

It's the sharing part. So what I say to people is that permanent storage isn't about, oh, like everyone's going to be able to see what we've ever done. No, no, no. It's really about the stopping the distribution. The search ability on something like RWeave by default. it's like it's finding a needle in the haystack just like if you got into youtube's database finding the one video that you've created in the s3 bucket is a need in the haystack so it's like

it's really about the new systems are going to be built around this idea i truly believe that people will will learn to use permanent storage and then build systems around that around stopping distribution if they want to delete things and a really kind of cool idea here and this is a shield to lit protocol, but with lit protocol, which is this kind of encryption protocol and a way to have essentially link smart contracts and on chain stuff with with encryption to control access of specific assets, you can you can actually, if you upload a video to a video to ARWIF that's encrypted or to bundle that is encrypted using lit, you can essentially instantly revoked people access to it and you can essentially stop people from being able to view it as well. So that's also

a really cool way of doing it as well. So you have the censorship resistance and and the ability to revoke people's access to that data under certain kind of decentralized conditions as well. So like the three-part answer is yes, there are times when you want to use temporary storage. But the way that I see things is permanent storage is the way it's going to work. And there are 100 different ways to look at this and 100 different ways to really solve this problem as well. It's not a reason to give up on the benefits of all the reasons why we're doing this. Totally. I'm glad you brought up lit because one of my follow-up questions was going to be. you know, what projects and protocols you kind of see as complementary to something like

Bunler. And it seems like that definitely, that definitely fits that question. So yeah, I think with a lot of these primitives that are emerging today, I think the and the composability that's enabled by crypto networks, you have the ability to create really powerful primitives. and determine parameters around them that work for you. Yeah, no, it's really true. And the two things I'll generally say to that is, like, yes, there are lots of problems to solve with this. But generally, like, it's not we create a system there are new problems

to throw away that solution. It's like, okay, there are new problems, therefore there's going to be more solutions to that problem. And just to kind of answer the secretary question as well, or the primary question was what other protocols do I see as being, complementary. I think LivePier is an interesting one, which is that I see a lot of trend around video. And there also needs to be, again, going back to decentralizing and prototyzing the whole stack, I think LivePear is going to be a big kind of component to a lot of these solutions going

forward. When there's a decentralized YouTube, decentralized TikTok and there's Lens Talk, Lens Tube, that all use LivePear and bundler together as well. So I think that's also going to be a very cool protocol to look at in the next few years. Well, Josh, it's been an absolute pleasure having you on. I really, really enjoyed this conversation. And we went a little bit all over the place in our journey through understanding our Weven-Bundler, but I think we did a pretty comprehensive job. So really appreciate all of your time. Likewise. It was really good. Thank you.