ABOUT THIS EPISODE
Episode 9 · 4 years ago
SHARE THIS EPISODE
Episode 9 · 4 years ago
Hashing It Out #9: Rick Dudley
ABOUT THIS EPISODE
Welcome to hashing it out, a podcast where we talked to the tech innovators behind blocked in infrastructure and decentralized networks. We dive into the weeds to get at why and how people build this technology the problems they face along the way. Come listen and learn from the best in the business so you can join their ranks. All right, guys, episode nine of Hashing it out. Welcome back, as always. Collins here. WHAT'S UP, column Hio? How's it going, guys? And today our guest is Rick Dudley. Rick, you want to give the give the the people what they want. And quick introduction as to who you are, what you do and how you got introduced since the blockchain space. Yeah, what happy to do that. Hi, everyone, means we Budley. Right now I run and advisors consultancy business called vulcanized link. We're building a database product, or sort of a passion there solution, called volcanize DB. I advise a number of projects in the blockchain space, review white papers, help people of mechanism designs, etce. Etce worked on over twenty projects in the last two years. I started working in space. In my February, two thousand and fifteen. I got into it a friend of mine had a very small sort of like hacker conference and and this was in two thousand and fourteen, I think, and it must have been. It must have been in July of two thousand and fourteen. I could be wrong, but some of the people who came were were Burge coin enthusiasts and and I and we know, made a relationships. are talking, hanging out and stuff. And then in November of two thousand and fourteen they invited me to hear this this presentation in New York City or is and the felium meet up with that feature that a lot of the cool people even to Gavin the talk. Maybe like Jeff, I'm not. There's a bun of people. I don't remember exactly, but there's like a whole gaggle of them. And then Gavin and the talky talk and I was immediately very skeptical. I was the pretty much the first question and most of my question was, you know, do you guys have any idea about these other things in computer science that are like well understood that kind of make what you're saying found unlikely? They're like no, we don't really know about those things. What are the things? You kids but loss over that. Yeah, so it's all my questions were around like where they looking at how pack this works? Where they're looking at how Cassandra and then I started explaining things that used raft. Of the US have any familiarity with these algorithms? I basically yeah, well, the leader based protocols, right, yeah, based consensus, sort of like they decide on a leader and then there's a way of actually determine at the leaders correct and then typically time based to so I think you have like an interval of time period where the leader has to respond and everybody votes and elects for a particular leader and then that leader kind of decides and everybody sends their information to leader who then delegates and they can confirm that. Yep.
So so asynchronous business team fault caller or not necessarily in those cases, business team fault coller protocols, but that consensus protocols or agreement protocols. And so I said, I ask that they knew about that stuff, and now I'm not really and then I and then I sort of mentioned that fifteen seven block times with full agreement would be difficult. sympaticals of the topography of the Internet and they didn't really have a response for that. I don't think. I mean uncle's in some reguards are response to that, but uncle's have these sort of really undesirable side effects, etcetera, etcetera. And then and then at that meeting Joey doing was like, okay, we'll launch you like stop asking these but really hard questions and we'll talk about it later. And then so we ended up talking about it later. I ended up working at consensus for four months and then I left consensus. Did a little road show for a company. Then I ended up working at Monax. Then while working at Monax, consultant jobs are starting to come in and then my consulting job load was greater than my moan x load. So I left Monax. Great guys happy to you know, happy to his work there and then and then I said doing the consultancy full time, and the consultancy sort of shifted and then it was originally sort of a blockchain platform as a service sort of play. I'm not really a bus de sales kind of a person, so we weren't really able to those three at us at the time. Both of the other people have since left the company eventually. I think this company was eventually just formed with two people. Now there's just one person. Just needs the former business partner left. And Yeah, and so I consulted on some, you know, wellknown projects. I've did a lot of architecture work in earlier Mesa Goo, I did a lot of architecture work for maker one. That I think really kind of I don't know how much it is really made it into the white paper. I just don't remember. I work on Casper with lad and Greg and I still in somewhat active in the Casper community. I try to be, but it's like pro bono works. That's hard to find the time. And then I've contributed architectures to a lot of it. I said, you know, basically twenty different client engagements over the last two years. I have, you know, several contracts in flight right now and that's sort of and I can get into real deaths about what it is exactly I do for my clients and exactly you know all that. It's primarily federated topistate networks, so you can think of them as like side chains. That's most of what I do is sort of mechanism design social chains to make sure that you haven't sentive alignment, and that actually includes that a lot of stuff. That's not a simple it's not like a turnkey thing like that. People are sort of asking like how how would you I? How would you teach me to do my job? And if I well, I have. Basically, I started being really in the computers in in like really into it in one thousand nine hundred and ninety six, and I, you know, I was out fifteen at the time and like I still drawn experiences from that to like design the mechanisms that I design now. So sort of like while it. You know that the long time between then and now. So it's hard for me to tell people like read these books, read this article and then you rligned, and I've definitely had those discussions to which has been weird. But there's a guy, so I was having this chat conversation with it. I was...
...like, you hear that? How do you do what you do? But why have you thatt this? Have you got that? And I actually have a medium post. Why talk about but Bysnantine Fault Talkin sensence papers and he's like yeah, I read all those papers in like he said that like landport was really easy to read and understand, and I think that parts of where import are very easy to understand. But Fund like supposing of the problem in landport, I think is very elegant and but the solution, but where he proposes a solution is you know, any part of why diystantine fault, Paler consensto systems have developed so slowly is because there wasn't, frankly, isn't still much of a need for them, but also because the material which is fundamentally difficult to understand, that it's this exotic stuff that's really difficult to reason about correctly. So if college graduates are telling me, you know, whether whether Hebrews or whatever, that this stuff is easy to understand, then there's some gaps. There's something that I'm not understanding about what other people don't understand, because I see broken systems every day. I mean all all I do all days look at broken mechanisms and argue for hours of people about how their mechanisms are broken. So, okay, okay, so let me let me stop you there. What does broken mean to you? It means that they are not providing Byzantine Vault. Are, strictly speaking, like I can be very precise in my sort of way, but I don't I'm not referring to necessarily a body of literature, but I can I can say very precisely as my own language, or in my own mind at least, that there are certain types of resistance that your network should provide, and they're not necessarily economic or Bayesi and rational actor types of things. Like like, like rational actor assumptions are pretty worthless. Economic assumptions are helpful, they're super helpful from an operational perspective, but from a design perspective they're pretty worthless. Yeah, and so and so you have to have a set of mechanisms that actually provide both a carrot and a stick for the various actors in your multisided marketplace to continue to transact in perpetuity. And I feel about see, you know, Casper CBC, like he says. I like. Is that? Is that going to be? Is At actually like friends are just sem some someones that you don't think are our bft. I mean there's a lot of famous things, right, and when we talking about well, be about mechanisms. Are Not just talking about consensus algorithms, right. So some of my pet my pet peeps right now, token curated registries, prediction markets. That Dan mormer's work on depault. I have a lot of respect for Dan warmer and he's he it's taken a bit of time, but he's pretty open and public about he's on the record as it's saying that a lot of his stuff isn't never was intended to be. Bysantine fault aren't and it's not. So those are sort of like famous examples that I think like readily come to mind and there's obviously like more weird corner cases and stuff. Right, let's say so, then I guess question is, why? Why are people designing systems that aren't bft if there are people like you in the world who are able and willing and excited about it, and I want to make them isn't fault time. What's old? It's actually pretty shirt forward. It's really expensive feature in a lot of different it's expensive along multiple axes and it's just not worth it most of the time. I don't think there's anything wrong. I mean there's a little history of people building up networks. You know, I seq or any number of like I'm sorry, that might be too old for the audience. I forget how old I am sometimes. What you know of the SQ team at one point, if at all? Yeah, they got bought up and for one summer I worked with them. Yeah, from all. All right, so, like messaging platforms are notoriously not be Ft. Right. So so,...
...but you know that's not really necessary, right, your customers are still using the platform. Messages don't get mangled, like anything, still works out right. I think that the reason. There's just this long history of not meeting that type of security and then bitcoin sort of came around and then all this bus sort of came around and there's all this marketing. You know, I think that Bitcoin's main innovation was marketing, not technical. I mean, I think the pet I don't want to diminish the technical contribution at all, but people don't use bitcoin in the limited use of it because of the technical component they use. It becomes the marketing and I think that the marketing is what's really transformative. And so actually that that's sort of a security sort of way of saying that a lot of people come to me saying they want a BFP solution and I spend a lot of my time talking to people and saying, okay, but you don't need a blockchain for that. Okay, you don't. But you don't need consensus for that. Okay, but you don't. As you know, a lot of my time doing that and trying to tease out if there is a real place to add does team fault tolerance, and then like okay, can you actually do that? And I've I've kind of honed that thesis to a pretty precisely at this part and mostly I work with federated proof of state networks providing multisided market places. So I think that's a great it's a great I guess move it to something in the trying to ask here that work, because you spend so much time saying you don't need a blockchain for this, you don't need a Byzantine fault tolerant consistents Magative it for this, without giving away all of your work in terms of potential clients, where do you need these things? Why is it important to have the type of stuff I think? I think that there's like the two major fecs. So, like I said, it's sort of a multi sided marketplace and in particular it's a multisided market place where the cost of insurance on a pro transaction basis is too high exist today. So today you might have tried to build a multisided market place with the traditional computing system, but there's so little trust in the system that that you putt ensure the transactions. So people never build the systems. So there's so there's no transactions, so there's systances don't exist right. So so one is sort of the cost of insurance, and the other is even when people are trendsacting and they do have insurance of some kind, it's an extra legal activity, so you don't have a place to actually art treate when you do have a disagreement. So an example of that would be something that trade finance right, or like, you know, ensuring innern ships that enter international waters, or more precisely, like suring an item that's on a ship that the international waters. Like a can be very hard, even though everyone is sort of an agreement about the reality and everyone's willing to pay the insurance and everyone's willing to do everything, how to actually settle that up, and that in? What currency is it in, and then what jurisdiction and like? That's the currency actually have. Of course, has an impact on the jurisdiction. So there's like these sort of other kinds of and of course picking you know, perfectly legitimate business scenarios, right. So there's a there's a third case that is sort of like to get into the gray area where, you know, let's say you're in some sort of political environment where there's a tyrant for some sort of regime. Right, that is like clearly uneffable when you have these sort of extra legal problems as well, because, although you're transacting in an honest in their way, there's some, you know, in the large actor trying to prevent you from doing that. But then you know it's the legal for me as an American citizen to do business with you, you know what I'm saying. And then, like, hopefully audience is sophisticated and they can sort of reading between the lines from those three examples. You know what I'm saying. But girls are kind of like the major issues. The yeah, that read it between the lines thing going on...
...there. I think even one example that I use in particulars that one is when a dictator comes in, takes all the land titles, Burns some and then distributes to land his generals. What happens when he's out of power, that they're totally regime. An example. I mean the link by like to point out that I actual Fiat currencies only last with like twenty six years on average or something, and that's pretty intense given how long some of the currencies have existed for. I mean that means that there's currencies like Fiat currencies coming and going at a pretty high rate, you know. And so yeah, I think I think those are like very much. You know, land registy stuff is really big. One of the things that I sort of took for granted growing up in North America is we have a really real busts are directing system for physical buildings. Like, you know, you can say, you know, forty nine mock street or something and that and that's a place right and you can figure out how to anyone can figure out how to get there. Even in Europe, you know, still you know the rest and role, except that that assumption doesn't hold. And then the rest of the world they's just like forget about it. You know. It's like they literally, you know, you go with the guy who knows how to get to the village right, and that's you know, if you're not with that guy. You don't know how to get there. And so just even that sort of thing where it's you want to have some constatuity in spite of whatever government or political activity is going on. So there's some utility and blockchains for that stuff as well. Right. It makes perfect sense. So now, yeah, I think I think we've all kind of identified those cases. What kind of cases are people coming to you where you just like hey, I mean you have to be specifically hey, come and you don't mean a blockchain to that, like what are you doing? Unfortunately, to get a little in the leads. There's a lot of data availability problems that are sort of that emerge when you start using a blockchain that can't really be solved with a blockchain. That's really the big one for me right now. That's sort of what I'm focused on, the volcanized DB, and it's the one that is sort of a big issue with effium sharting solutions as well as other people's. I mean it's a fundamental issue with starting solutions, and so that's the one that really comes up a lot. It is around like data storage, data availability, data retrievability, BLA black, and they're obviously this file corn. There's a lot of people you know in that space, but you know, I really like see you a lot. It's not tho sire, but it's not really there are kind of in the right part of the problem space. So they're not they're actually really good protocol. But there's other protocols where it's like, you know, you guys aren't actually solving anyone's problem because you can't make availability guarantees, and so that's probably that's a big one where people don't need a blockchain out in the other w obviously, is is pretty much any collusion where you have a centralized authority that has some hand wavy edict to decentralized and it's like, I mean, I see, I can say that substractly, without without reference to many fetters. You have this plan where you start off initially centralized and then, because you the leading freedom or some BS, you're going to take your profitable business with shareholders and counterparties, you know, other businesses that are making money from using your platform, and somehow you're going to like, I don't know, like go to some logician or something and put them in a box and then you spend the box around they're going to come out and they're going to want to take on all this liability of operating a mode and and there's somehow going to transition from being a centralized, you know, cryptographic protocol to being a decentralized cryptographic protocol. Is like the sort of high level members sort of running a federation to then eventually becoming a fully decentralized protocol...
...where anyone can participate. In quotes, I've had many, many people come to me. I mean in fact, that world map is very popular. It's not just people who comes to me asking that world that in many, many places and for me, each one of those there's there's you know, there's three different states there with two different state transitions, the first state transition being from the centralized ability to a federation and then another state transition from a federation to the close federation, to an open federation. And both of those state transitions to me are very difficult to reason about. And it's not and it's up surely economic problem or purely business problem, where it's like, okay, so if we were actually successful in the first phase where we were centralized, then why does anyone want to take on the additional risk because they're not going to get better performance, and that's sort of the argument that we know that the performance is going to decline. So I mean that's the fadeoff. So why would someone you know go from the centralized one to the decentralized one and then, once you somehow convinced them to do that, so that would these federation members are at are not all ticking on all this liability? He's okay. So why did these guys who spend all this money and all this time to be able to absorb this liability and make revenue in that turn around and sell that technology, that that knowledge right not into not the computer technology, that the operational knowledge, to the general public? And I just had just throw up my hands on that. I see what you're saying and there are some things that centralized systems just do way better. I think Corey said that many times themselves. However, I think the the number one place I see that particular federated conversation coming in is when you have to do things like regulators have to be involved or just supply chains. Actually is a really good example of court. Were talking about that before you got on the column. He's playing to skip called tactorial and I've I've got some experience in the supply chain space myself. Not a whole lot, but you know, it's been kind of a topic of interest for the past year and I think when it comes to supply chain, the concept of visibility and end visibilities kind of be like the Holy Grail of that particular industry and that the the current model that supply chain has is speed. Being centralized means that you can only kind of see within your per view of your vision, your your your assets as they traveled through the supply chain. Mean you can't see things coming into your supply chain very well and you can't see things once they go out of your supply chain very well. So a lot of businesses, such as ups and Fedex, have added things like better tracking capability on individualized package in order to packages, in order to kind of like get you the ability to kind of see where they're going once they're out of your supply chain. But that isn't quite solve the whole problem and a lot of the response time on that is within like what an hour. So so a lot of the use cases that I'm seeing is I want to know not only what where my package, where my where my materials are going or what materials I'm buying, where they're from, but also the state of them in that temperature controls and and humidity and and various other things as as they go through the supply chain. I want full of visibility into how they're being treated and how that's actually going, and I see like that requires a level of trustless mechanisms in order to make it happen. Absolutely so. I mean I've definitely work on those projects over the years, you know, designing those systems of people in your I think your analysis is absolutely correct. But what I would say, strictly speaking, is that in a lot of those cases, what you're looking for is a is a set of protocols that facilitate a couple of different things, or more than a couple. One of them is simply cryptographic atestation. How do I assert that a statement is true using cryptography, or how do I sign something cryptographically and say that I believe this Theed to be true? But that's one thing, and that that that really is outside the poor view of Byzantine Agreement or,...
...you know, consensus. And then there's this other thing where like, okay, I'm not that I've made this at the station. I need to time stampus right. So I need to get a bunch of people work in the consensus is helpful here where I need to have, you know, I want these seven people to sign my message to prove that the method really was generated at this time right, right, a nonalize consensus mechanism. Those things you're flowing through supply chain right exactly. And and it may be that, like you know, there's a regulator or a or O em who's who's, you know, sort of leading that time stamping process. But if able to go down or not be available for whatever reason, you know, the the time standing process can still can still continue. And so it's interesting about about these sort of there's a lot of these sort of platforms where you're doing this massive stream of cryptographic at the stations or cryyptographic claims, and you then need to pall that down into something that can be set into a blockchain as a as a as a true statement. So you know, again, the blockchain for me is very much more about the multi sided marketplace and and these cryptographic claims are at the stations are the things that we're actually trading on in that marketplace. So to the supply Cheam Model, I think, strictly speaking, obviously there's a synergy between a supply chain and a marketplace that the supply chain itself by its very nature. The only person who can tell me who, if the guy whoves the thing off the truck, is, frankly the guy who moves with them off the truck. Now you can do you know in we're being kind of get the dancer here, but you can have someone say I put this thing on the truck. You know someone else that I pulled the thing from the truck. But ultimately there's no real way to get consensus on those. Statement's right. You just had the kind of is. Have you heard of the project called loan? What's it called? Loan? It's a geospatial blockchain kind of thinging, I'm I'm not really film, film space from space on the maybe I got it. Maybe I got it mixed up. Yeah, I mighty phone space. So home space is a client. I lie. So I actually provided a prop of location architecture for them or work a lot on that. And again I would argue that a lot of that is face. I mean actually we have three different consensus algorithms or three different types of agreement systems in in film, and so so we're doing, you know, synchronous agreement, a synchronous agreement. We're doing like a lot of different things there to facilitate that. And so that's I mean, I mean you're doing really pure danced when he says thing, you know, who can actually at pass to the package moving, because you have to trust the package, you know. I mean it's it's until you have your puss in the package, you're trusting someone. There's someone in there that that you might believe because of some claim they made on a block chain, but when you're believing their claims, you're just believe in their claims. There's not multiple people that can attest to those claims. Yeah, yeah, yeah, it's also gets to recertify if you're going to be doing any sort of like handoff of and then we do that now anyway, to some extent. I think I'd take a quick step back here and discuss kind of the idea of, I guess, distribute consensus and in the way that it came to nature and Bitcoin, and that was like bitcoin came to life, and I think this technological innovation was that it allowed you to trust a system as opposed to a group of people, which then allowed for digital scarcity. That then got rid of the me like the mediators that, in this case, were what you relied on to say I move money from some one place to another, and so you displaced the trust from a single entity to do that type of thing to a system where a group of people that were heavily incentivized the follow the rules. And so the consensus mechanism of proof of work basically is heavily aligned incentives.
That's that only carrot, no stick, as you were saying earlier, and what you got out of that was the ability to displace trust that not rely on humans, but rely on a system him that you believe to be fair. And isn't that kind of where you want to try and find some like reasons? The use of blog chain rease, they distributed consensus mechanism is when you want to get rid of trusting people as opposed to in placing that, whatever that trust is, into a algorithm of people who were should be acting according as they should, based on incentives and distant sentence. Yeah, and I think that's kind of the stuff where you're bringing up with like as things flow through a Francisis why chain you need to kind of have a system that's non human that kind of, to a high mathematical probability, can self verify itself. If the users of these systems or not are not typically contributing to the consensus mechanism, you're relegating that to a group of people who should be acting fairly. So if you're not, actually I'm not. Okay. So, theoretically there's nothing stopping a system from having like thirty nodes inside of a crate and each one has their own censor which did basically basically runs its own little form of consensus. I mean you just you know the the amount of computational work to fraud, to fraud that would be kind of sniffly high if you have a long enough chain going into the crate. So it's kind of like one of those things where you can build systems, I think, which are like little isolated truth mechanisms that exist outside of like a major train that doesn't require human intervention. You could still kind of have people put things in and out of this truth Machanism and it will it will pass through this chain of ownership and you'll know that in this particular portion, it belongs to that particular, you know, trust mechanism and that trust making news has been checking itself into this main root trust mechanism this whole time. So you know that it's also true. That makes sense. Yeah, so that's sort of how phone works. I know a lot of I don't the way that I engage in my clients. I don't have the time to track every project that is like plagiarizing from a client or every project that sort of have the same idea at the same time or all these different things. But because there's definitely a lot of plagiarism and space, frankly, and I and so so, like with the case of film space. Yeah, it's about the zone anchors having synchronous agreement amongst themselves. So they're using the synchronous algorithm. They didn't, you know, publish that the synchronous Algorithm has been operating to an eight, to an asynchronous not work like like a like an etherium and in through factly, like you said. But those zone anchors in that case are relatively large areas. So, like you know, you know within cities, like several city blocks or something like that. But yeah, if that's strongly agree with that. But again, and just to be like so somewhat pedantic, that agreement amongst those those four synchronous zone anchors is not really the same thing as, strictly speaking, as like a blockchain. And so it's just about knowing what type of Algorithm to apply to what type of use case and and why you're doing that. So so I think that. So, in one hand, I do agree with what you're saying. On the other hand, but to answer the sort of the other sort of populate or position that was proposed there, I don't really think about it as replacing people. I don't think of it as people or somehow untrustworthy in this way that that machines are not.
I do have a pretty like extensive background in psychology and definitely theory of mind and I and that has certainly informed my view of it as entities. Like I very much think of these actors in the systems not as people or businesses, but as sort of these agents that have will and motives, whether that agent is three people or seven people or robot or whatever, or company, whatever it's, I don't try I try to keep those assumptions out of my architecture. Sure, and and so I don't really so a lot of that construction is very like sort of alien to me or frustrating to me, because I don't think of it as like, Oh, we got rid of these unreliable people and put in reliable computer right, because that's not what actually provides the security. I mean, people love to say, you know, trust in numbers and all this type of stuff, but without getting all that into it, you know, there's no way you can prove that there's no backdoor in your Intel processor. There's no way that you can prove there's no backdoor and your arm you know, your qual calm base band, which, of course there actually are certainly backdoors in those. You know. So we're not really it's not really about that. I mean it is, but that's almost to me like a digression, right. I'm what I'm trying to ensure is that there's insensive alignment via tariff and sticks, between the different types of entities within the system, and and as types, not as individual entities, and I think that that's actually where bitcoin has a flaw of model, right, because the the the guarantees that can be provided to an SPV qualent regarding privacy and service and delivery that are sort are very weird. And bitcoin, like Bitcoin, isn't, like, you know, perfect right and mean. It went through a lot of revisions. There's some really amazing work around mack, the Moto Consensus. That really is novel and brilliant, but there's a lot of like weird thing, you know. But so much mental energy was put in, focused correctly in that area that there's other parts of bitcoin that don't make a whole lot of thing and and we sort of sorry can be from those as they make and rephrase what I said there, or at least kind of how I view this thing up. To start off, a blockchain is just the data structure that provides a one of many properties, but the main property being a succinct summary of the entire state of the blockchain that can't be changed. So it's tamper evident, that necessarily tamper proof. And then what makes a blockchain network is the consensus mechanism of the Group of people that come together to agree on that state and then somehow how a way to add state right and that that's a blockchain network. So people need blockchains. That the data structure for various reasons. But what consensus mechanism you use is heavily dependent upon how, like what type of people will be using this system. And so when you're creating these types of systems for people, solving that problem or answering that question on who's going to be used it and what do they care about each other is a very different problem, depending on whatever the hell they're doing. Is that? Is that exact absolutely what we're saying? Yeah, yeah, absolutely. So. I really strongly agree with that and and that's why I ended up moving away. Well, I wasn't a big bitcoin proponent or anything. I'm more of a bitcoin proponent now than when I started working on these mechanisms, basically because of what you said, where at first...
...my intuition sort of my background as a systems administrator, which I had mentioned before, but in actually deploying these consensus systems, you know, rafts sort of systems, and was like, oh, we'll like, you know, we solve so many problems without using bitcoin. BITCOIN is really super focused on this one type of problem that it solves really well, which is kind of an exotic problem like in the world of problems, and and so yeah, I think. I think that that is kind of a lot of times when you look at projects and you talk to people and how I end up saying where you don't need a blockchain for that is these aren't people who studied how to deploy distributed systems, let alone these centralized systems. So they're just not using the tools that exist for that, already existed before Bitcoin, for solving their distributed systems problem. That's fair. And and they learned about distributed systems by looking at Bitcoin, and so they try to look at everything through the Bitcoin Lens and that's how you ended up with the term proof of state, which I think is a horrible term, because people were looking at, you know, businantine fault power consider into systems which had pre date, you know bitcoin and were cited in fact by Bitcoin, you know, in the Bitcoin Development through the Bitcoin Lens, and you get this very distorted view of what the problem space is when you look at it through the Bitcoin Lens. And so I think that's you know, most bitcoin developers don't have this problem. You know, most, most people will serious in the bitcoin space in terms of architecture don't have this problem. But but many, many people who talk to me about. You know my work and what have you do have this problem. So I think it's interesting your brought up wrapped and this is kind of a tangential question question, because I actually had some problems with IPFs cluster recently, not that recently, I guess maybe astounce been about six months, but I noticed that like consensus mechassisms like raft are far less resilient than say, a proof of authority network, meaning that I have to have a certain number of nodes available that is higher for them than anything in proof of authority. I think it prove for thor it will work with like one note. Really, would you say that's an advantage or disadvantage is some of these other systems? That's the interesting questions. So we're the the trade off there that was really being discussed is the reason you need a lot more nodes is because you're actually using that. Actually use that. That over it like you're you're using the resources. The reason, like, let's just take the same let's say it's like so, actually, one of the things that we did at as vulcanized as we replaced. So there's a there's a database called cockroach DB. I'm not going to get into what that is now, but it's a it's a popular fault on database. It's based on raft. What we were able to do at vultanize, I think we maybe actually well, we we there's we replaced rafts in that system with tenderment for right and practically, you know, we didn't really run a lot of tests on it, but you know it worked at first blush. So let's just take like a sort of a simplified version. When he took something like etcd and you replaced sorry to get all in the leaves, but we got all the shows about. Okay, awesome. Yeah, so you know. So if you book at some of the ETCD and you replace Raft there with tenderment, what you're going to find if you actually have less right availability because the loads need to get agreement amongst themselves on the rights. So you're right through put on, that network is going to go down and you made a fairly fixed tradeoff for you know,...
...stronger available, you know consistency guarantees at the sacrifice type of right availability and unfortunately, just this sort of dove tails and to confuse conversations about the caps there on that let's avoid. Let's try to not get into that quagmire of misunderstanding and just say that their things are tradeoff in this model. That seems a lot like pop but strictly speaking is not really the same thing as cap mum. Yep. So I think what you're saying, if I could just translate that, because I is that basically because of raft I have more consistency at the sake of availability, but because I can go all the way down to one node on a proof of authority network, that node pretty much, if they were to get down to that point, I would not be guaranteed consistency. Well, in the case of the PA, you're basically faulted. Yeah, if you're, if you're really at one. Ressus to the concrete numbers. If you had a seven nodes that and you're out and you're one node, that's up. Your faulted. Right, so that data that you're writing to that one node isn't really isn't really meeting the availability threshold. But what what definite? Okay, thirstrys another way. So quick, quick, for like say for seven, you need for available at the time order to continue the blockchain. Otherwise it holds, it halts. Right, right, exactly. So right, and so that those put those four nodes. So in the raft with the you have seven notes doing wrapt and your seven notes doing tender minute and they're just running etc. On top your seven nodes on rafts are going to give you a higher level of throughput in terms of especially in terms of rights reads. It should be the same in theory. Right. On the other hand, you'll get no rights per node out of raft. Then you will out of out of tenderment. As you remove nodes, that right availability goes down in raft and it doesn't go down. And you remove those first three nodes on tenderment, your right availability doesn't shouldn't really go down that much. I see. So it's but then you when you remove that fifth right node in tenderment, everything stops and when you remove that fourth right node in raft things continue that. Now you're in the danger zone. I mean now it's going to keep going. But as an operator you know that your networks basically done. And so in tenderment, instead of saying hey, we're giving were letting you guys run on this broken network that all level work again, they just stop it. Huh, because I think I've got lower than that on proof of forty first also, just over over fifty percent is not I don't think they got down face on the world at all. It's a it's a thing. O. It's a good wors strictly. Yeah, it is. Well, I was able to write at one node. It's you're just writing. You're just writing. I mean you're just going to you know, you're in some inconsistent state. I'm trying to be delight about it. I see what you say. So it will allow it at that point. Yeah, so, okay, cool, we're getting see, I got to federate network, ten nodes. I go down on one, I'm still able to write because when everything stinks, back up and I'll sink with that one node. So you have to really trust that one note. Got It. Yeah, that's what I was saying. Okay, all right, cool, so we're on the same page. Got It. But with raft you need to and plus one our sorry, what how? You can't go less than what? You can't go less than half right of the nodes. Unavailability? Well, it's, but the read availability in the light availability are different. I see. What you're saying about raft is that it's with raft as you go, you know, if you're if you're in good consistuents...
...in terms of like above a halt state. The further node availability there is, the more read the more rights you will get, whereas with something like tinder with the tender ment, if it doesn't matter as long as you're not halting, it's about the same right throughput regardless of how many noes are available. So you get a better you get for performance with raft, but it's a problem once you get down past the halting state. Is that it is a decent way to summarize that type of thing. Yeah, I mean, I mean we're kind of cut putting from prevent the corner, you know, but that's the gist of it. Yeah, interesting. So I'm wondering you actually mentioned follow cone it, if you ever talked about any of you gotten into any conversations with people doing kind of distribute file storage at all? So we do it is vocalize DB. So that's that's that's a piece of vocalized DB. But we're not using strictly speaking, we're not using or global consensus for that. We're not making any claims about global availability or global consensus. It's it's basically a bond. It's a system where you use bombs and advertisements to create small networks which which you have guarantees about data availability within the reason you have that guarantee is because you can generate a proof when they fail to provide data and then and then get some assets, you know, get some value cleaned on another chain, right, and and what again with without getting too into the weeds about how you could generate such a proof, because you know it's very difficult to prove that something wasn't delivered right. This is the problem probably with the maybe I can get into weeds for you. Basically, what I've am not even in sight in the weeds is high level, a level. Basically, they've got made of consensus algorithms out there which basically the proof of storage, proof of availability, proof of network over proof of storage over time. So like there's all these like various approaches to try and figure out, hey, did this person only store it, but is he storing and delivering it to everybody across the network? Because one of the problems, it doesn't seem obvious to a lot of people I'm discussing right now, is that when you want to distribute your your your data, you're even if you like chunk of file and then send it to all those chunks, to those across the network? How are you going to know that you're going to be able to retrieve that file back at any time from those nodes? What they can do is they get hash your file for it's just so's just ignore the chunk part and say they hash your file like they do with IPFs, and then and then you go to retrieve that file, the only person they're sending it to is you. But if you want to share that file with your friend, there's your friend will not necessarily pick up that file because they might block them, they might not actually send that file in order to say, conserve bandwidth, but still receive the INSENSITIZATION model around the distributed file system. So one of the problems, that it's a huge problem right now, that I'm kind of really particularly interested in, is how are we going to I know there's this. I my gut tells me there's a there's going to be some kind of like a hash solution with this. How are we going to be able to reliably upload into a fog like, you know, distributed, decentralized storage mechanism and with it some degree of high probabilistic guarantee get your file back. Right. So, so, very crudely, what happens, and this example that you just gave, is you have created a file, you have made a market. You say, if you, you know, store my file and make it available to others, you know someone's going to pay you a feed. We don't need to really worry about who's going to pay for it. Some someone pays for it. And so you go out, you put that file out there, somewhat there, that order out there. Someone takes the order. There now the the published through the provider of service. That service provider is in basically, what you have on Chaine is that service provider has also agreed to basically pay anyone who proves to will. They...
...agree to do two things, right, either either they will or no, they agreed that. It's so saying backwards apologies. So when that person explain the service provider accepts the agreement, they also accept that if they don't prove, if they do provide delivery to people, then then they lose money. And on the foot side of that, if someone tries to provide generate a fraudus pre fulfilled delivery, they lose money. Right so that's kind of, in a nutshell, like how it works. There's a lot of problems, but I'm not getting into it on that. But basically, if you have it that way and there's this is a very this is a very we consented and the when the service provider is truly a third party, and that's something that I can talk about. It so like, like theoretically, that to talk about. I'm not in a position to really talk about the cryptography. So so basically, what you can sort of say is all right, because this service provider is at risks for not providing service. When I give them the file and they confirm that they receive the file, when someone else goes to retrieve the file, so that your friend goes to reprieve the file, that retrieval message is sent on like, let's say it's the theium, right, so they send a message on a theium. That message is proven publications on a theorium, the the bonds that everyone is making, or an ether. But all the file sensors are on a separate network. So now your friend goes to the MS that I want the file. Someone said, okay, I have the file and they start that process on a theium. Right. Then your friend from another message that says I don't have you know. And so you guys do that over a state channel or like a this like storage channel. Yeah, thanks. Yeah, and then something goes wrong in the storage channel for whatever reason, and the and the your friend posts a message to that same order that says I didn't get these bites from this provider. I want these bites from this provider and it has to be in those issues. But again, I'm going to just handwave my way through this. So they provide that through the art. Now, if the provider never respond and and I'm sorry, so I get this up. So when the when you're a friend in the provider, entered into agreement, they both put in a bulb. Yeah, but and so while this slow the stuff is I would put in the bomb. So there's a smart contract on the Theorem blockchain. It's game of FID so that they can handle file transfer. It's basically a generalized state channel, or maybe not even general, it's just a specific states that type of state channel which can actually facilitate the trade of information in a way that they can guarantee that that information theoretically guaranteed, that that information has been sent and received by both by the Center Party and the receiver. Yeah, okay, that's time. So, yeah, and so, and you can just do that sort of signed messages, right, and and broadcasting certain messages to certain people and so. So, while we're in the sort of failing the load where your friend wants to get some bites, but all the success. But first how would they transfer the files in a good best case scenario? Oh okay, so in in the happy path, the user...
...says, I'm going to pay this no to pro bite for these many bites. Here's a down payment, you know, here's an escrow. W should be part of the bonds contract. Yeah, yeah, right. And then you're also micrope, you know, and your micropayper byte and it's the micro until you do that Vido like a steak channel kind of thing. So it's a tit for tat micropayment per bite, you know, for for the data in the channel. And then, if everything happens complete correctly, everyone gets, you know, their last bite delivered was no bite withholding and and the the the payments have gone over that channel as well and everything's fine and and we just all go about our day. So that's like. I think that's I mean for me, sorry and because obviously I've been doing this a long time, but for me that that happy path is sort of obvious. I just I just forget to mention it sometimes, but that's so. Basically, at the end of the happy path was that they would do is they would take the the the receiver would basically certify that they got the same hash that was registered in the contract. He was real creck. So they would just okay, this shot free is the same. Damn, think architectual. They're the same thing. We're going to and then, and then, and then there'd be a time out on that, on that bond. And because there was no conflict, both groups, both count both parties in that agreement, would get there. Would get there, you know, most of their you know, the vast majority of their of their money back. Right, right. So that's happy. Now the bad path. Let's just there's a there's a bite in there. That's let's just say. Ay, Rick, you're breathing in your mic. Oh sorry, let's just say. Let's just say somebody, the the sender, decides that they're going to send a zero tout byte to our chunk. Zero up, Chuncoate, the fillow whatever to the to the receiver. Receiver goes, receives that and assuming no, like you know CRC, you know, no, no, no, no, no, no air correction going on here. They receive that fight and when they hash the entire file, they go this files wrong. Yep. Well, okay, so that's not quite a good example. But what let's say that there's POC right, so they hit at the packet's bad, right, they're not. They don't have to scan the whole file or the file is relatively small, so it's not too expensive to scan the whole file. They see that they are missing some data and then what they would do is they would request for that data to be replaced and in there to be a timeout on that. So if the data is not replaced within that if that, and then that the problem is, is that really you have to spend that replacement data on chain, right, which constans cost of transactioncy is very, very, very very expensive. So if you say that that missing data and so and so, if all of the missing data is provided on chain, then that user loses a little bit of money from there a scrow, but they get all the data tration channels. Yes, the right. So that's the next thing, right. So the next thing to do. So that's one answer, right. So what answould be to arbitrate that right. But there's also an easier answer, which is and the problem here is, like it's been a long time since I read the proof of retrievability paper, approval, verifier, Prov reprovability stuff, which basically says that all the data is there because you're interactively challenging the host very inexpensively. You're providing these very sustinct and...
...expensive proofs that require the storage to to prove that all the datas there. And in actually doing those challenges you're getting the full fill. So if you want to do the full chance, if you want to get the full file, you just do a bunch of these challenges and eventually you get the full file. And I think that I work. That's proving retrievability and you don't need any arbitration for that. But no one's done that yet to my knowledge. Like, like there's no profile bepastetalk on it, but there's a few V paste talks on storage and like they were all kind of like pointing out the flaws in each one and they all seem to have some sort of weakness. And so that's kind of where I'm kind of like, okay, we're going to build this largely centralized finals storage system, which is something I really want and what I want to I want to, I want to, I want to see that happen. Then, you know, that's when we really start taking back our data, you know what I mean, when we could chunk up finals and out. Yeah, I think the answer is to do it p top and and so the way that you know, philosophically or theoretically, that solve this problem is that the the publisher and the storage provider are the theme entity and that actually symbolifies things a lot. And and then you kind of go back to the sort of prove a verifier model. The problem at the proof, I think, if I will call correctly, the problem with the sort of proof of retrievability, file core and proof of spacetime issues are mostly around performance and not really around failure modes. I could be completely wrong about that, though. It's been over a year since I read those papers. Yes, a complex topic. I mean it's just full of sens where it's just personal fascination of mine. Am Glad that I could finally have like a discussion. This is the moments the word came up, I knew this is going to go on a rabbit hole. Let's let's let's bring it. It's come up for air for a little bit. Start wrapping up a little bit, Rick. What are you excited about in this entire space over there the next maybe six months? Yeah, so I'm super excited about people's location. So the phone space team that I'm working with from I'm very excited about, you know, the opportunity to build out that hardware, because it does require, I wouldn't quite a custom hardware, but there's a hardware component. So I'm very excited about that. I'm very excited about the work that, you know, maker dial sponsors, the volcanized DV to development. I'm very excited about about that work. I think the volcanizeddd as a cashion layer. Again, I didn't really come on to like pitch a product or whatever, but I think the vulcanized DD s solution ultimately will solve a lot of pain points in the community and sort of facilitate, you know, Open Open Source Block explorers will facilitate some of Kumas is the guy from me a mask. He's had these sort of proposals that have been that they've been slowly working on over two years with regards to making a theory and state available in the browsers and directly, and so so that that means that you can do sort of very nice things with wallets and contract watching and that a lot of related to all the work that we're doing the FOLKNIS DB sort of seeing those same pain points and and actually having some developer hours devoted to solving them. So I'm really excited about that stuff. I think this state problem in general,...
I mean we talk about starting, starting, is the same thing. I mean it's not just the starting piece of state availability. Obviously data availability is also a related top it to to this sort of state availability issue. I think that's a fundamental problem with any sort of smart contracting platform. So our space, that's another team I work with, also has sort of addressed, you know, has provided solutions or is addressing that that same topic. I think that I think that that, you know, people actually really I think we have to solve a lot of these state issues before we can start meaningfully solving the data availability for like for like movies or something. But movies are an interesting case because movies have keyframes. So there's an interpolation between frames, between every keyframe. So or Ian K frames and tripolate difframes and keyframes. I think, I just hope that's what they're hearing for. And so it's actually very easy to deliver the keyframes. If you just encrypt the keyframes, you can have some guarantees around the livery that are pretty nice. But for other large data file types, especially like state information and other other types of large blocks of binary data, having some sort of ad hoc distribution of that data that's primarily based on reputation, I think, is I think that's just a huge piece. That's like, sort of like a baby step, or like a half step from where we are now to the sort of the sort of data problem that file coin is sort of and swarm of sort of set up to address. I think I think file coin swarm. I like FIA coin, but they're different. So I think I think file coin and swarm the problem, the thing that they're missing. The reason I started thinking about the foam space problem out, you know, because I was thinking about that before I met that team, or engaged with that team. And the the problem that I was kind of solved was proving that my data in my file coin sort of Algorithm, you know from basing the file coin paper. How do I prove that the data is actually on two different spindles and and and film space actually facilitates that proof, and so I thank said. Once you have both of those things in place, you have this sort of proof of retrievability. Stuff really sort of out and you actually have like a even quasy viable proof of location, like like a pretty block solid one. I've I mean film space is much better than quasity, pausable, but like even like a some sort of you know something will go wrong somehow and you didn't fully truck that protocol for some reason. Even that would be an enormous step forward. And, like you said, actually having truly decentralized storage at data. I think that personal storage or data is frankly to mean more important and in easier to achieve. But they're absolutely absolutely right that, like large scale but PEDA Byte, Paara Byte, decentralized storage is really complicated and and and hard. Yeah, I'm looking into weird things like turbo codes to see how much are correction we can actually fit into a system so that it has some sort of a neat, you know, failed you know, resiliency to just whatever protocol used to it's it's a really complex topic. I'm really exciting. I'm glad we got a somebody to talk to it about towards the end there. So I appreciate it. But yeah, I know I was really great having you on Rick. I really, really, really, really enjoyed this stock. Well, thanks for having me. I'm going to do a little bit of advertising. I'm on twitter, primarily a F Dudley, a FDDLLY zero...
...at the end of that, and I mean that follow the best way to like follow what I'm doing. And although I was look, I guess some of my tweets are relatively cryptic. Again, I'm not really a marketing guy, are but, but, but it's really a lot of those tweets really off based on even some of my tweets seem completely some of my completely off topic tweets really are completely off topic. But like, if I'm talking about like government stuff or politics, that's because or like retweeting some political thing that's happened. That's because of the importance of governance in the blockchain. Yeah, yes, so it follow you on twitter and anything else in you social media other than that. Use vocalize, I think. What's your UIL for that? But it's vulcanized that I oh, you know, you can look at like an old landing page there about it. The the best way to reach me would be too sort of like at me at twitter, somewhat unfortunate but maybe kind of cool, like a weird futuristic way of doing things, or find you're at a conference. That's how I met you and that's how I I guess. So we became acquaintances. So, yeah, yeah, it's great me here, Rick. So, yeah, hopefully ill having to have you on again at some point. That thirst that. That's what her s and far listen, nurse. You can find us on spotify, itunes, you name it. Hit the subscribe button, give us a review on Itunes, do whatever you can. Hit US up on twitter, hashing, outer man pod. I'm at at Corpetti and Collins at Colin Cuche. Talk to us, we'll talk back. Yeah,.
In-Stream Audio Search
NEWSearch across all episodes within this podcast