Hashing It Out
Hashing It Out

Episode 31 · 4 years ago

Hashing It Out #31: Pokt Network - Michael O'Rourke & Luis C. de Leon

ABOUT THIS EPISODE

This episode features Michael O'Rourke (CEO) and Luis C. de Leon (CTO) of Pocket. Pocket is a chain-agnostic decentralized AWS for blockchain full nodes. In a world where full nodes become more expensive to run, Pokt aims to have people host their nodes in their network by registering it with their Proof of Stake blockchain. Using Pokt tokens, someone can rent usage of the full node, using the node's stake as a guarantee of availability, removing the concern of maintaining one's own hardware (virtual or otherwise) to create a decentralized application.

...into its work. 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, we're back episode thirty one of hashing it out. As always, I'm here with Colin Cuche. Say Hello, Callin. Hello, Colin Nice, you're getting better at reducing what I say. I'm gonna Start Making more difficult from here on out. So you have to really get into it. You have to do funny voices. Man. Do you do any? I do a lot of funny voices, but I need to be a little drunk to do them, and the time is not good to be drunk today. Yeah, we've recorded drunk ones before, but it's fin it like seven o'clock at least. Yes. So today's episode we're here with Michael and Louise from the pocket network. So what's up, guys? Hey Glory, let's having us on. Hello, thank you for having them. Yeah, of course, and I'm curious to see. I have a lot of questions about how how fucking network works. But to get started, why don't we get an introduction as to who you are, how you got in a space and what the pocket network is from like a tenzero feet over few sure. Yeah, so, Michael and I got into Bitcoin in two thousand and thirteen up to that first run up, and that's super interested into it, into it then, and I'm also an ILS Belper, so I've been a nice of Belper Welt four years especially, and when we started working on pocket about three years ago, a two and a half years ago, I really got into smart contract development and theory and it's being least. We had met at a previous start up and been really deep into a theory um since then. And now we're building. Now we're building out on birth. All Great, Luis, you want to do the same thing? Sure, so. Yeah, Michael pointed out, I've been doing somewhere development from a bit longer, but I didn't get that much change the cryptone to like we add around the same time they've started developing the Bridet. I was aware of the technology and the implications but I never liked go deep on to those first conversations. So from that point online it's been a whole a whole run into into building and expecting out this this whole product. So that's that's interesting. Like there's a lot of developers are getting into the space. What was your background before you did this and what was your barrier entry? Yeah, so basically I was more of an product oriented developer. I focused on end to end, from business idea to actual execution kind of projects. So that led me to do a lot of a startup work and then I got aware of the technology, not because of the whole price thing and people getting rich, but rather about the profound implications that it will have on security and things like us your authentication, the centralized user authentication and all that. So that really picked my interest from a systems and architecture point of view. But it didn't I didn't get to the point because the tooling and getting into...

...it it was so moret so commersal. So by the time we started talking about pokhead and the initial idea, I started to see, I'm improvement it through, what's picking up. It was easier to get into, for example, a smart contract development and all that. And although all those things allow you to have a bigger we find space on ahead, space into what the technicalities about. So I see pocket as almost providing services at layers zero. Can you give a kind introduction to like what the point of pocket is and like what what problem you're trying to solve? Yeah, I would say that pocket is like decentralized infira really. So what it does is incentivize people to run a full node, put, IFN API layer on top, and what the protocol does is route a PA requests from a client to the right note for the right job and there's a randomly selected committee of validator notes that validate Goo safe a requests. And once those eight therapists get validated, the people serving them get paid or in pockets. So the protocol, it's an inflationary protocol and it Mints Tokens to those providing the work. Another way with it explain, it is like almost like aws. How aws you know if you're if you have an apple slack for example, and every apples storage and compute, for example, right, and a bus acts as a layer in between the actual application and those core functions that that are needed to build those applications. I'm a blockchain developer and I want to build something using Bitcoin, or I want to build something with anonymity using see cash from my narrow or a new file storage. Well, I need to be able to talk to that blockchain. So with pocket, pocket is a infrastructure layer that sits in between the developer and the actual blockchain they want to communicate to. And in yet what it does is incentivized with run this full notes and service as APL requests. Now, this is only work for atherium. No, pocket is blocking agnostic. So we built pocket really modular and we've got basically it's a plug in system that we've built and these plugins carker from all the lease but they're around a hundred fifty lines of code and right now, as long as you have a javascript library that we can work with, it's very easy for us to spin up these plugins. So the idea is, I mean we think that we're going to live in a world with many, dozens, hundreds or even thousands of blockchains governing our lives. And for the many blockchains that are coming out and test that today and the many that haven't been invented, well, we think it'll be much, much easier for them to build out a plug in really simply through the pocket network that just basically abides our interface, and all of a sudden you've got a network of hundreds of thousands of nodes willing to spin up your infrastructure as long as they've developer demand. So really trying to make it really, really easy for new blockchains coming out and blockchains developers actually build those applications. So you're trying to provide the service for people to say, all right, I want to have exam, I'm creating a Dapt, I want to have this type of functionality. Okay, that requires just blockchain. I'll then call that appropriate API to the pocket network to get that information securely. So and so forth. So exactly. Okay. So this is somewhat of a I'm seeing of a recurring narrative right now, at least in the like the lower technical space is this network layer and how it's actually done, and it's quite difficult. You're seeing a lot of the conversations in the theorem around moving from deaf PTP to live PTP, like how you're actually making peer connections and maintaining those connections, especially when the type of note they're using, maybe they have a lot of churn, which means that, like, it comes on the network, off the network. So, like you're not really sure on the availability of all the notes. Like how are...

...you addressing this? Like what are you put? What are you building on? or You could you create your own? Does that even matter for what you do? So currently, sorry about that. Currently are our care in architecture design doesn't really occur too much about that. We established a protocol for life miss so there will be a set of nodes providing lifeless checks between their peers where their peers could get penalized economically a speaking, if they don't, if they failed the lifelessness. So in our particular case we're also trying to achieve networking modularity in the sense that we want people to connect to notes in whatever network protocol they want to reach them. Right now we're focusing a lot on http and web sockets because those are the most popular, but we want to allow two we want to allow the notes to connect between themselves using whatever kind of network, in layer day they choose. So could get a little bar into the liveness test that you're talking about. What does that mean to test for liveness? So we have two basic requirements right if you're up and the speed at which you respond. So we haven't put the actual numbers there yet, but where we have the framework for it rates, we're gonna pro do a sequence of steps every x amount of time and if you fail those steps to respond, first respond and second respond within a certain time frame, then what you're going to be under the subject of you failed this lifeness check and what the protocol establishes is we want people to, we want notes to to always maintain reliability and availability of their service at all times. But that's not always the case. We with with the peer to peer networks, notes can come in, a join and leave at whatever time they want. So what we want to do is establish a protocol to let them join our leave whenever they want, but at the same thing, whenever their present, they need to be a life during that period. Okay, so let me try and get this. I'll orica standard users story here. Someone do eaching the pocket work. I have node infrastructure and I run various nodes for whatever services that I do already and I use the standard node infrastructure that those networks provide and then I interface that with the pocket network layer that sits on top of it and I say I'm running these nodes, I would like to like broadcast these services of the pocket networks, that I'm going to serve this information to the pocket network, and then I basically get checked by the pocket network to make sure that those nodes are running and I can serve that information appropriately. And I also stake pocket, which will get into a little bit, which then kind of guarantees or and also penalizes based on this live and sections just set, and then I get paid for serving information to DEAP. So it's instead of so on the DAP layer, all they would have to do, I'll sensibly is say I want to connect to these blockchains. Pocket Network make that happen for me correct so. So I actually want to bring up a conversation you had with Alex then decide to get a few weeks ago and talking a lot about making it as easy as possible for developers to access this blockchains with UX and Ui. I know Alex space is focusing on a bunch of the UI UX for the user, but I would say that pocket is actually focusing on the UX for developers. So we've got a suite of St case, for example, that we've built that make it really easy for developers to...

...communicate to those pocket notes and basically weave abstracted all blockchain queries and transactions to the two things, queries and transactions. Right, so the plugins that we build or that anyone else builds basically conformed to those, to that abstraction and allows it to communicate easily to the pocket note that the person is right, that someone that someone else is running. Okay, then I have you. Have you learned changed? Know about some of the competitors that are doing something similar? Like I see DAP node as big, somewhat similar to this type of service. Yeah, that node, you've got, quick node, you've got. There's a couple other ones. I'm missing a lot of people that are trying to decentralize, and fewer right now, because that's clearly a problem within the your theorem ecosystem. But by I guess what you're doing is trying to make it more broad than that. So you're not only serving a theorem information, you're serving arbitrary information. And what's interesting about I fear, like if you think about Justin Fiura and the sheer amount of volume of transaction requests that they get. Generalizing that to other network seems like a lot of work and at least like a lot of band with for for a network to uphold her. That's a lot of different things and in one question. But what do you think about that? Yeah, so the first part you're basically pocket is here to basically incentivised some of the runnerful note right. So, Luc if you want to talk to the bandwidth a little bit, but we think that this is kind of like a core layer for blockchains that area. It's not. Everyone has an Infuria. Yeah, right, and back he him is the only protocol that has an inferior and and we know we consider pocket as more of a application specific watchain, meant specifically for people who are running full notes with these. Then apis on top. Yeah, and if my if I might address the bandwidth issue, not all the transaction data goes through the polk. It blockshin because that will imbuse bottleneck by define what it's actually happening is that the small coordination layer on which book a note, who fills your request, is what we're trying to achieve in our coordination in the in the Protocol Coordination Layer. So after that the connection happens seamlessly between the client and they know what we call a service note, the actual note that is fulfilling the API request. Had A later stage after that API request, youth ful field. They had note will report to a set of randomly chosen validator their work, that it's done. So after that work is approved, it's they're going to get their reward. Okay, that's a lot of sorts. A lot of the WORKAP INS off chain and you know, originally pocket is actually a set of smart contracts on etherium. But if you look at, for example, in FRY scale, they're doing over it's and billing make their requests a day. Now even batching that up and submitting that to a smart contract gets really expensive really fast. So part of our solution actually was so just build out a completely separate blockchain. That incredibly decreases the cost of running this. So how, when you say you're communicating with the blockchains, how do you commit to them? If you're like, what are the what do the commits look like like? What if you're not doing what in fear dones and patching things up and sending it and making it still pretty expensive, what are you doing instead to resolve these requests. Okay, so that's a very interesting question. So, if Michael pointed out, we have both on off chain component on an own train component. So how do we mantain security across...

...all those layers? So basically we have the sort of Shard that it's called afficion and as session is basically the connection between a client application, a set of service notes and a set of validator notes. So there is a small time frame and we're trying to reduce that time frame as much as we can to avoid collusion. During the small timeframe, the client is going to use as that set of service notes to full for them to fulfill the actual API request. And that happens of change. The client signs every request saying Hey, I want this data and I'm signing that that I am who I'm saying I am with this, with this private key, and and then on the service note side they sign the response to that request. So now you have a set of signatures that prove that the client actually submitted that request and that service note actually fulfilled it. After, I. After the request is actually served at a later stage, the service note takes the requests he's done and all the signatures and sends it up to the validators and the validators confirm first identity of both by doing a certain knowledge proof, which is something very standard, by by now using the signature and knowing, Hey, this is the client, that this is who requested and this is who responded, and based on that, in on that set of the data, we have to basically two main interactions. We have queries, which we represent by allowing a set of Metadata of at which blog and on which state beat the node read the data from, so that way the validators can go into their own copies of the blockchain and check that same state directory, if you may, and check if the data correlates. For transactions, is way more, way simpler, and you only need the transaction Hash and you use the transaction hash. You check the transaction information both ways and then you just need to hit approve or deny. The validators get into consensus of chain by signing, doing a transaction signature chain, and then that becomes a batch of transactions that goes into the actual pocket block chain, so that way we don't have to record into our own blockchain every single transaction, because that will be too expensive to do anyways. So what we do is we refer to the validators to actually badge these transactions of chain and then submit them to the blockhing. Of course, everyone involved is a state, so if someone misbehaves or tries to collude, they get significant, significantly slash, and that's where they crypt economic model helps keeps the they keep the infantive aligned. So help me out here, because I see I mean I might miss something here. So that explains how you're kind of batching it to your layer one solution, the pocket blockchain. But let's just say I'm trying to write a deceptionalized application on top of Bitcoin and I have one bitcoin in my wallet and trying to send I don't know half of it to somebody else. And in the meantime, while you're doing your work, I actually send, you know, seventy points in five bitcoin to somebody else and now I don't have the funds to support that transaction. Like, how are you resolving these sort of like the cross communication between the the resolution layer on the actual blockchain and your layer one solution? That's what I'm not sure I'm quite grasping yet. So the lay your one solution doesn't actually care...

...about the other blockchains. To be honest, that lay your one solution only cares that the validators and got into consensus, and that's proven by all the validator signatures and they and the thread faction batch data. Then your one bog volution doesn't know what it's Bitcoint, what it superior, what it's wet. They only care about which client requested which data and which service not what I provided it and which validators actually did the validation. The one who validate all that are the service note at this stage of when you submit the transaction and validators when they actually validate the work that was done. So let me let me rephrase that in three steps. The client needs to submit the right request, and I remember every blockchain have protections for things like this, like replay attacks on that. If I try to submit a second transaction, it's going to have a different knots. So me as a client, I have no incentive to go ahead and do that right. So in that particular case it won't matter. In the second step, the service note is actually economically incentivized to check the transaction formatting and data before submite. A need to to the to the actual blockchain because if they fail they need to report that they fail to submit that transaction and get they get less money. So they're they're economically incentil to to check for for transaction format. And then the validators are the last layer of defense and they'll check that both the client submitted the appropriate request and that service note punt in the okay. So I see this as a service provider coordinator and then a kind of a post methodology for incentivizing that coordination, one since they done to a good way to sum up what's going on there. So, like I said, of trying to picture this good, I'd say a good portion of our audience as a theium to people. If you think about how Meta Mask automatically connects to a fire basically on a default thing, but you have the option to change your provider. With this, potentially could do is basically change the entire thing to just, you know, go to you the pocket network and the pocket network sorts out who you get connected to ex time. Then that's more generalized because it's more than a theium. It could be any other network idea, this, bitcoin, etcetera. Sa Right, because there's a couple things I want to add. A pocket node can be running the top twenty cryptose and work right. Let's say bye bye, bye bye through butt. And so one person is running those top twenty notes, but then you've got an entire network of people running those top fluty notes. And the other side of that for developer, whereas, granted, infior is free, but other services like block sideper block team and things like that aren't free. Instead of a developer paying a fee to the network like you would normally, you actually would buy our token and stick it into the network. So, as a developer, be like a onetime transaction and you would stake your are tokens into the network, and what the network does is throttle your throughput. So the amount that you can access the network, the API request based on how much you've staked. And that's a way to do like spamp jection. Imagine. Yes, that's correct, in one layer, because the first layer, remember, it's always they what we call the relay layer. There the layer where the actual service goes through. There's also, you know, it's an actual blockchain that is providing the finality guarantees and it will work pretty much like any other blockchain. Will have its own jase on everyth interface. It will have is that you can send road transactions, but we won't be posting, for example, a smart contract platform on air...

...or any other general blockchain things. We will only need what is extremely necessary to actually provide the the coordination, the service coordination that you just describe. Can you can we take a little to turn to what that what the pocket block chain is and how it works? Some Lissen the details behind it, of course. So the pocket blockchain is the actual the lowest layer on the whole pocket network system. So what the block pocket blockchain does is provide finality guarantees by having a set. It's going to be a proven stake chain that is going to have its own set of badly dators and you're gonna be able to propagate transactions to it either through a relay through through our book at note, or you can just run your own and submit transactions to it. And and and what that will do is it will hold, it will of course, keep the the decentralized layer of everyone's balances. It will hold the layers of the stakes of everyone. It will host a little bit of Meta data with every stake just to know enough about each note as taking or each developer is taking so that the coordination can actually happen from that, from that information, they other layers of the pocket system, which are session layer and and the client. The client, the service and the session layers will use that data as the source of truth take. So we're using the blockching as you will use any data ways in a normal system. If you think a normal websitag, you have up front end, you have a middle where you have a data bas so what we're doing is we're taking that, we're taking that and converting it to a version that work for us, by saying, okay, we have a client layer, which is basically the interfaced and users are going to use. You have a service layer, which is the one executing the actual transactions to the different blockches. You have a session layer that the validators will use to actually validate all that work, and then you have the blockchain layer, which provides the finality of all the work that happened, of change, and I would amuse, I would assume, the people who are running the notes and also the pocket that work notes like just by interfacing with the pocket network, you basically run a pocket network node as well. And by running a note, are you automatically validator. How does that work? So it's very obtain our our client, pocket core, is going to allow you to do all at once in a single instance, just like in get, for example, you can disabled the James a RPC, you can disabled different modules just to suit your needs. The pocket core client is going to allow you to do all that. So, while we ambition is more of a service of how on an architectural piece, in an infrastructure machine, will work, where you will want some instances of the blockchain running in a set of subnetworks, you will want your load balanced relayers and you will want a Ald your security measures in place to protect your notes from outside attacks. And what I want so in in receiving in summary, what I'm trying to say is that you can't pick and choose which actor you want to be in the network. You can be a blockchain validator and just participating in the proof of state consensus that it's keeping the finality guarantees of the blockchain afloat, or you can participate in the relays and means the OKT tokens whenever you do work for the network, or you can participate as a validator after passing a set of requirements and validate transactions for other notes I'm seeing. Sometimes I'm something I'm curious...

...about. Now, running a bunch of notes across various networks is computational expensive. Sol Span with expensive is their way to run. Say, like I could be on my pocket note on one machine and point to a bunch of different machines because the likelihead of running all the stuff on the machine is not reasonable. Yes, that's exactly how it works. Are plugging system is actually an interface that allows you to connect, for example, to a load balancer where you're running twenty get instances in twenty different machines and it actually load balances. Or you can actually do very cool stuff where you can say, okay, all the read requests go to this load balancer and all the right requests go to these other load balancer. Because we're thinking about the infrastructure provider when we're designing all this. We want people to have all the options that they can, to miss a much architectural components to the best of to the most flexibility that we can allow in terms of security, to actually go ahead and configure your notes however you see fit. People. Some people are going to probably find out that having taller machines, which means bigger, more capable machines are it's probably going to be a bad approach versus having forty befriend notes running different services and and you think I load balance third to coordinate at all. So yeah, we're trying to keep it, I. Flectible, less possible to seems like this is the tooling try. You're trying to make tooling for people to become their own generalized and Fura for other people. And then that's a morel like the like infrastructure side of using your software or using your service or the platform. The other side would be to just make it easy for doubt of all ave to say I need information from this network, go get it for me. Pocket that does that. That got a reasonable like the two sides of what's going on. And yes, this platform exactly. You can give it like a two steady market place just like that. It's a developer driving platform. So you know the helpers are using pocket. There will be a market of those when it's been up to service those developers. And, like you mentioned that the token is minted inflationary market. Okay, we talked about the kind of economics around this. This token, how it works, what it's like. Supply is how things could move. Like I'm trying to see, like there needs to be a value, like I need, I need to make money as a as a infrastructure provider serving requests a bunch of people. If there's, like, if the value associated with the cost as social with running this infrastructure and serving information is much, much, much larger than the value I'm getting on the pocket network, that it doesn't, why would I keep using it? And like, how to, how to, how to? As the economics plane of there. Yeah, great question, and that's so where we are. So I think one of the most unique things about pocket is our domic model, because there's a bunch of knobs that can be turned and and part of latching this is, you know, testing this and seeing what, how those knobs affect the liquidity of it's open in the present oken things like that. But but in the end there's three main economic mechanisms that are in pocket. There's staking, there's minting and there's burning. The the interesting thing about pocket is is we don't have a static mint like etherium does or bitcoint does. Your most block chains to our mint is actually based on her a thei request. So as pocket gets more popular, more pocket will be inflated or more pocket will be created out of the air. Right. That being said, if pockets getting more popular, more people have to stake our token to use the network. So there's kind of a balancing act there at equilibrium, you know, over the course of time. Another thing that's interesting is that normal transactions on pocket, the fees,...

...are completely burnt. So what we think it in at maturity of the protocol, which we don't know when it's going to be, but we think that the the profit that a note is going to make in the end is going to be the Delta between how much pocket was burned and how much, I. Extra pocket was staked during a given amount of time. There are three main burning mechanisms in the protocol. One is the fees, so every time I do a number pocket transaction, that gets burned. Obviously, if you're a bad actor, your tokens get burned. And the third part is we have a Dow darkly inspired from where to make a proposal you have to pocket or you have to burn some pocket to actually see bigger proposal. So between those mechanisms and the growth of staking, we believe that will actually, at maturity, keep the the the total supply, let's say, of the Tokens, relatively even or maybe even hopefully deflationary. Kenny modeling on that, like you're trying to from trying to take pictures at and like what it looks like a pend and possible ways of like manipulating this type of thing. Yeah, and what the cost would be for staking note infrastructure. If it gets to too costly to actually stake in and participate, then you have to do you have no other way to get tokens in the system to kind of correct. So so ours it's we've taken a bit of learning for life here. So it's a dynamic staking model. So whereas like with they've capped out at like two five hundred master notes or something like that because of the price of you know, it's going slowly. Ours is that, I dynamic state. So that number, as a developer, for example, if I have to stay two dollars with the pocket and then the price goes up, you know, triples the next day, well, I don't want to have to stay six dollars with a pocket for the same amount of work. Right. So there's a dynamic staking mechanism there that actually is based on how much is pup, pocket is staked and how much a pocket is circulating. So we're actually so this whole you know, I'm mix thing. We've this is what we're really, really deeply working on right now. Tracy, she's working with this. She's still a ton of modeling and we're really working through the best way to go about this and the best way to execute on this plan, because it is a different model, because because the way it's going to grow, it's going to actually grow based on the usage of the network. Right. So part of that is making it expensive for me a self deal, for example, things like that. So so if I'm a client and I have a node, well, I'm just sorting myself a peer request, but I'm on needlessly and playing the network, and that's that's a problem. So so we've thought through a lot of these problems and you know, it's hard to test it in still as live. So so we can't wait to actually test our models and our theories when the protocols actually left right early subtest that. Yeah, I I got go ahead. Least I what's gonna say that we were we're gonna fasting, fast, yeah, no, no, when we say but yeah, that's a very like important point to that's that's actually yeah, I understand. I understand the correction there and I see this. So in the process of creating this, so your your platform grows and gains its value based on the service request it's like, basically the traffic it gets from various networks. So you actually see your success is not relegated to a specific network. In fact, it gives a lot of usage to tiscus across all of Blockchain, depending on how much your your systems being used on what decentralized networks, node infrastructure is actually in most demand across across the board, assuming that people are, you know, all using pocket. If I sit do you, have you considered what type of Metadata you leak for the users? So...

...trying to think of, like looking at this from aference, your forensic analysis perspective of the type of data that flows across your network and what I could gain from that, as well as just data analys in general, how I could extract usable, insightful information from the data flowing across the network and the USA statistics of ill thought about that at all. Sure we've thought it about like quite considerably and in every type of the design we are we are alway. We are always asking our felt how we need to use the least amount of data to get the most amount of reward out of that data. And basically, from a developer point of view, we're creating this whole authentication system based around policies, so to allow developers to pick and choose which models the benefits their APP the most in terms of user authentication, because we are striving to a model where if I want to create a APP that not back and the developer and I don't want to host any infrastructure, as want my APP, my users to connect to the website or download the APP, they need to be able to go ahead and do that. That's from the developer point of view. So, from a developer standpoint, they will have they will create developer IDs, which is a subset of Metadata, and every user install, we're calling it a user install, but if you go to the web, it's going to be every user that that is using the APP. Every instance of the APP will actually require to have an account, of a pocket account in the background without the user in doesn't have to know about it, and they use that account to sign the transaction. So in that particular science we're not doing any KYC, we're not doing any you know, we don't need to reveal any data. And from then those a standpoint in the only piece of information that we can't get away from reading is where is the note endpoint actually is, like what's that domain or what's that Ip address that you need to connect to, because in the end it's not actually at the centralized DNS where you provide a domain name and you don't even know what the Ip address behind that is. You actually need to know where to connect to and that's part of the whole coordination layer system. So that's the only piece of information that the notes leak, if you may. Where they whenever they stake, they need to actually specify the endpoint to which clients will connect to to service, to get service. So I hope that answers your question. In terms of the blockchain notes, it's if you think about Gath for example. Now, if we, if most of the audience is a firm friendly in Gat you have bootnotes because it uses cat embla, the cat embia algorithm for peer to per connectivity, and you need bootnotes. That actually help you build a routing table. Those bootnotes exposed the IP address or domain that you used to connect to, and then in your peer list you have all the Ip addresses and that the that then and notes that you're connected with have, so you can actually send and receive data. So we believe that with this minimum amount of information, and of course we will have guide length, we will have better practices for our node operators who actually go ahead and keep their note safe, even if they're exposing a public facing interface. But that's a stand our web security like do need meeting the other videos. You need to mitigate...

...old sorts of scanning into your network. I know those sorts of things. So that's pretty stim so, just so you know, a sidebard corey for a little bit. I'll be frank. I wasn't getting it at first. I heard your explanations and one of the reasons why I wasn't quite graspec it is because I kept hearing Infuria and it doesn't sound like that's a strong enough analogy to what you're doing, because if you're a basically takes. I'm sorry if I'm jumping in and you just, you know, derailing this, but I have been trying to figure this out, genuinely a but looking over your white paper, I've been trying to dig deep in this and I'm like, cory, I like I don't get it. If it's like an inferior like if you're a bad just things and uses the theory as the main truth mechanism for the entire decentualized application that I'm using. So if these guys are trying to do something I could hearing decentralized Infuria, then basically I would expect at some point I would send a transaction it we get resolved on the theorium now court. Yeah, you're shaking your head. Corey's corries corrected me on this and I need to saw. I think this is probably one of the main points of confusion I personally had, and I cannot see myself being the only person. Is when you bring up in Fura, you see one model of doing things, which is basically the centralist services. You dumped your stuff into and it will put it in the blockchain for you in a batch process, and that's not what this is at all. Like it's a rest, it's a it's a it's its own resolution layer. You have your own blockchain, which is something that also through me, but I got and I understood and I figured why that would be useful when it comes to cross Brock blockchain communication. But you're not acting as at you're actually the APP player, like you're you're the transaction layer, you are you are the resolution layer, you are your own resolution layer, meaning that everything resolves to your token and then you can exchange that token for value on the other networks. Is that correct? That I'd finally get it? I no, I didn't know. I don't think so. What do you think? Get, help me out of here. You say everything resolves to our token, like like, like our token you could think of is the value of all the validated APA requests that all the hundreds of thousands of many infurias are servicing in our pocket network, right. So, so everyone's doing a bunch of work, servicing a bunch of baps as kind of like the middleware layer, if you will, but it's its own protocol and sits next to a theory and successive point. Everything like that. Are All these apair requests to do all this work and the result of that is the minting of our token. So you could say that, yes, the tokens value or the tokens work to have been minted. This is result of the work done in the network directly that sense. Hopefully there that clear. Anything for but maybe it's that this might be easy to say. This like I'm having is on on them up. Fundamental problem having is I want to use a theorium. Right, how as adaptable am I using your network to facilitate that? Okay, okay, what's use like? Cling? You got seeing, you have the quick? Okay, that's the question. Yeah, I think it would be easy to elucidate how this works by like going through the life cycle of the request answer process as well as the payout from the from that service. Sure, if I may a lustrate. They if they they, if you're a life cycle and then ours, maybe it will create the best analogy. Because here's the thing. If I'm at that developer and I want to connect to a theium, I need to run my own get or party to note, right, we're clear up up until that point. It so basically most that developers don't want to do with that because get coope can be quite resource consuming. It can be, you know,...

...on stable at times like where it's like my get is of the stuff a thinking and all that, and I don't want to deal with that. I just want people to send cats to each other over the network. Right. So what happens? I submite a request from my dad into get note that it's alive and that it's thinked up, and I'm able to send my transaction to that note and that note magically will propagate that transaction all the way into the bloction and it's going to be confirmed. I'M gonna go into it intersten and I'm gonna be able to see by my transaction hash that my transaction is confirm until that point. That's the first life cycle. So where Infiraad goes in, it's hosting that get note. I don't want to deal with that. Like I'm not develop Grama I us, you see. So I'm I only hold my APP in my server. Yeah, that and that brings up the awus analogy that Michael brought up earlier. Now it's all starting to click. I'm sorry that took me so long. So basically it's a rent as a rental service sort of for for host notes, like a meaningful notes. Okay, I get that now. My question is that doesn't solve the throughput problem? Does it technically, because you still have to manage the the the whole, like, you know, I need to get my cats through and there's too many requests, right. So how do you solve that through that? So letthers two sides to that coin, like there are two two angles. So first, yeah, we're not a layer two solution, that it's trying to solve the scalability problem. But and the other side of that coin, there are things infrastructurally speaking, that can ease up the UX of APPs using pocket versus using a rock connector or using Justin Theoria. So, for example, one of those things could be since you know for a fact that they know that you're sending your transaction to is economically incentivized to have the transaction be put on the blockchain, we are thinking that there will be a secondary market for a kind of an asynchronous service where I submit my transaction and I get some sort of ticket, like if you will, get like for waiting in line. Right, you get a ticket, and now you know that there's a third there's a note that is economically incentivized to put my transaction on the blockchain and I can use my ticket to query the state of that transaction, so that way I can build ux around that. I can help facilitate my users through that, a synchronicity of blockchain design and product design. Now, that said, that's not a core part of our value proposition. While we're what we're proposing is actually highly available notes that are willing to take under the request every network. Leave leaming. I'm through BOOT capacity. It's not something that way, because we're not asking those network to mollify their clients. We're just connected them. Gotcha, and there and so okay. So this takes care of a lot of the issues that all so people, people typically deal with, like keeping their nodes up to date or whatever. I like. You don't have to worry about that anymore. You can check version for them. You can, yeah, you can check. You know. Oh well, this fork happened. Your node have that you're subscribed to, decided to hop on this side. You don't want to be on that side. It'll automatically put your stuff to the correct, you know type. So let's just say etc versus etherium split, for example, like you would actually go, okay, I want to theorium, but I don't want to jump on, etc. Where as other people might go, I'm going full etc now that that developers are driving the conversation a little more, and then demand for the market places driven by the developers of the centralized applications rather than the people who are simply hosting the the nodes themselves, which to me is actually...

...extremely interesting because, you know, like BCH and whatnot. It's showing that that Hash power doesn't necessarily drive the conversation, that developers are driving the conversation and that people using the coins are driving the conversation. So the end user, whether they be a developer somebody just exchanging outsets, of the ones who are actually driving the value that that that is that is automatically going to be taken care of through your network. So my adapt does and actually have to care. It just goes where the the users are going, and that's that makes it a lot simpler for me, as somebody who just wants to develop a depp and get it out, to not have to worry about that kind of stuff. Cool, okay, I think I get it now that and you that guarantee is based on people using pocket so like the the ability for someone to say, all right, send me this information. I don't care how I do no discovery. To find it is take it up through pocket. But that requires people on pocket running that node infrastructure to be servicing those requests. How do you how do you get the the the level of adoption required to have good service availability while you grow? Great Question. So we've got an entire plan right now to have as many notes as possible running pocket by the time we watch the protocol we have. So if you go on our Github you can see that we've built an etherium and point. So etherium got pockets at work. We've just finished our AON and point and we've also done in our chain and point, for example of a working another company. They they're they're actually building out a one chain plugin right. So what we've done is we've open sourced, open sourced our entire a WOS CON FIG to make it as easy as possible for people actually spin up their own infrasttructure. And another piece of this is through, through running this infrastructure, we're actually going to be doing a Dow, simple Doo with an air drop on the theory, and so a good chunk of our tokens are going to be there and people who are participating in the as a note and pocket will have a vote as to what happened exactly. Think of it just like ash down will have a vote as to what happens with those funds when proposals come in to build, you know, some interesting the APP or some wants to be another note or something like that. So so we you know, we've already talked to three companies who actually want to say as a note of pocket and frankly, our stuff is all there for anyone to run. So our goal is to have as many people running this as possible, to bite so that by the time the protocol is live, they can just plug in and actually start participating in the networks. So we are doing our own Kyc in that sense, where we're working with companies who we think are reputable, who are strongly, who are talented, technically strong, who we think can really can really do this kind of a heavy, practical lifting. Right, this isn't necessarily the's this thing we're going to do. That being said, we are trying to make it as easy as possible for, you know, kind of like the one click, Hey, I'm going to run my own a US with my own you know, end point kind of a thing as well. So when we are trying to make these as possible. But but, yeah, and if I may expound of one, Michael Fed Michael Cover the pretty booth trap up the initial launch of the network. But in the future will developing a process where the market is going to be able to vote on which networks are accepted and which network out body there. Because me, as a service note, I can go ahead and explain whatever network I want and advertise that in the internetwork and if I client wants connect there are now, but those I don't get paid. So there will be a whole process to accept that network as as a new network to support, and that's all gonna be community...

...driven. So that that DA leads me to my next question. So it sounds like you have a governance model kind of built into this. It's got an election process. It sounds like a doll. What is your so that drives you right to the consensus mechanism. You say your proof of steak, but there's no solid proof of stake. That's just like general public and open at the moment. The ones I've seen that are successful or delegated proof of stake. Is that what you're running, were still are experimenting with different not as Michael said, but as general concept. We are running proof of stake, but that all the finalized details are not out in the public yet. So we can like officially comment to that, because we're looking at different models on how to do it. Well, we'll can tell us a little bit more about what models you're looking and why and some of the first accounts you're seeing, because I think our developer core would really like to hear what's the results of your experimentation on that have been, for sure. So there are two if when we say proof of stake, that are we're actually talking about two things at the same time. So one thing is what we mentioned before, is the blockchain layer, keeping the blockchains pun free, having transactions being put on the blockchain safely and sex securely and and the they whole economic of that model is basically I will stake an amount of pokt and I will actually participate in the consensus of which block gets written to the chain. That's one side of the argument. The other side of the argument is the proof of stake for the validators under service notes and the and the clients. So the clients will also need to a stake, but we're basically calling another stake category. When you stake to be a note, that's going to have its own transaction type. That's going to be not stake. That not saying that's going to be the official name, but just to simplify it, it's going to be a sort of note stake where I input enough made a data to qualify me as a note and they, and then the blockchain layer is going to check that and it's going to Bote or whether or not that transaction is valid and you're officially approved as as a note. So that part of the proof of state consensus actually is validator by by your federated note system. So I want to one for a note to become federated, they will need to become a service note first and work enough to earn a reputation. We are using our reputation system we're calling a Karma for now, and you Accrue Karma by servicing the network enough. When you reach a certain amount of Karma and you, on top of that, increase your stake into the network, you're going to be able to become a validator. There's a there's, of course, the possibility that we may end up having a double step there, so we can actually let the community decide who becomes a validator of the network, so that part of the consensus is actually driven by that process. Catcha, and it's sort to be clear, there are certain theotbilities, I'm going to call it, in your model. But the idea is that by exercising the power that having too many validators under your control, for whatever reason, to manipulate transactions with the value the very token that you're investing in. Now, of course, that that itself means that your value, your value stored in the network, has to outweigh the value gained from gaming the network, meaning that...

...if you happen to have a bunch of validators that you own and you are trying to squash a competitors transactions for getting through, you, you would basically the verbal situation is that the amount of steak required to do that would outweigh the cost. That would outweigh, you know, squashing the competitor. In some ways, that is that correct assumption from what I'm understanding, on the economics of this. Yeah, that's one of the key indicators that we're using when, when the signing the economic polity, because that what they are. What we're trying to do is not the behavior of every actor in the right direction. So we incentivized people to behave. US like to behave that best as possible. Behave good right, because sometimes it's not as binary when you're talking economics. It's not as binary as if you're a good city thing of of the network, and or if you're a bad city. Sometimes there's a spectrum and we're trying to take all these things into consideration to operate in the least a margin of error possible. All right, so what can we expect? A test that we're shooting for a q two thousand and nineteen. Okay, but after you know so far, do I lem where the word like the human but human being side the worst. That estimating. Yeah, this, this, this technology, is not easy. Setting hard deadlines on making sure it works properly is is shooting yourself with a foot a lot of cases. So, but it's nice to know when you can start to anything. How do people get in touch with you and start interact with you to help with build this process out? But our website we've got some open research forums. So we put literally all our thoughts in inspired by at research, so feel free to check that out. Obvious start. GITHUB has got a ton of activity and it's in a repost, and you left to follow us on twitter at pokt network as well, and our slacker pretty active on our sloft. So I would say those are the primary. I would say slacking, slacking our research forums are the too primary and give up. Of course. I would do primary way to get hold of us nice and that's always. Is there anything that we should have asked you or you hoped we asked you that we didn't get around to? You can see a full working version of our of our stack. We release an APP called the neeto quest. Actually, a few months ago we built it at Ethono situs. I don't know how long that that was, but may Luis and Pavel when over there and back there and we built this fun out. It's like bananto quest and it's like pokemon go and geokashion. So you finally is out. Once we really bananas and they were returned to you. Seven Dios, seven twenty one for completing the question. It's a fun, silly APP, but it kind of shows the power of our technology and we actually open source that entire APP. So you got to see as an IOS developer, it's fun create wallet, to create a Wallet Right. So we've tried to make it as as possible for people to build us a pocket. Nice, awesome, cool. Thanks, guys. Looking forward to seeing seeing some taps belt on this. I can't wait to play with the test not work sucks. Has So far out. I'd like to get my hands on it now, but you know that's just so Peopol yeah, thank you for sure, all right, but wraps it up. Thanks for come on the show, guys. Thanks guys for having her. THANKS FOR SH.

In-Stream Audio Search

NEW

Search across all episodes within this podcast

Episodes (134)