In this episode of the DeFi Download, Piers Ridyard interviews Michael O'Rourke, co-founder and CEO of the Pocket Network. During this interview, Michael describes how Pocket supports Blockchain developers to achieve DeFi’s Web 3.0 vision.
In this episode of the DeFi Download, Piers Ridyard interviews Michael O'Rourke, co-founder and CEO of the Pocket Network. During this interview, Michael describes how Pocket supports Blockchain developers to achieve DeFi’s Web 3.0 vision.
Piers 00:04
Hello and welcome. I am Piers Ridyard, CEO of the decentralised finance protocol Radix, a public ledger entirely focused on bringing DeFi into the mainstream. This is our podcast, the DeFi Download, a show about decentralised finance and all things crypto, where we dive into the details of the projects, assets, and services that are powering the DeFi revolution. Today, I'm joined by Michael O'Rourke, co-founder and CEO of pokt.network. Pocket allows developers and users to trustlessly access the full API for any blockchain client across a global, distributed network of node operators. Michael, thank you so much for coming on our show.
Michael 00:44
Piers, thank you for having me. It's a pleasure to be here.
Piers 00:47
Let's start by just taking us on a journey. What is Pocket's main reason for being and why did it come about?
Michael 00:58
Yes, absolutely. At a high-level, Pocket is a middleware protocol that sits in between the user of any application and the blockchain that they're accessing. What this does is, when a user opens the application, they are then accessing a full node that Pocket has incentivised for them to use the application like they normally would every day. This concept of Pocket, incentivizing people to run full nodes for any blockchain, is really important. To understand why this is important, you have to go back in time to the beginnings of Bitcoin. There's a famous saying in the Bitcoin community that's called “Don't trust, verify.” This really gets at the core of why Pocket is important because a big reason why a lot of us got into this space is this idea of financial sovereignty, owning, really, truly owning my wealth. When you say “Don't trust, verify,” that's actually “run a full node, sync the entire blockchain of the Bitcoin blockchain and verify that my balance is what the Bitcoin blockchain says it is,” as opposed to what my bank says it is or whoever it might be. This is the most important ideal as to why Pocket exists and a big reason behind this— You know, back then, you had to run a Bitcoin full node to even access the Bitcoin blockchain, right? If you've ever run a Bitcoin-Qt client, or whatever it might be, frankly, it's difficult. You have to be technically proficient. Back then it wasn't expensive because Bitcoin was a small blockchain at the time but you still had to be pretty technical to run a Bitcoin full node. In fact, that's actually why Coinbase exists today. Brian Armstrong was like, “Wow, it's hard to run full nodes. Let me build a wallet that removes the need for my users to have to run full nodes.” That time was the first departure from “Don't trust, verify” because, at that point, users are not running their own full nodes but they are trusting Coinbase.com to run the full nodes for me.
Piers 03:28
Let's unpack that a little bit. What do we mean by full node? What is it? What's a full node on Bitcoin?
Michael 03:37
Yes, so a full node— You know, the name, the word blockchain, it's— A full node downloads every block in, say, the Bitcoin blockchain. In that block, in those blocks, the state changes, or the balances, or the ledger is recorded every time I download a block. At its fundamental core it's a peer-to-peer network, so, I'm downloading these blocks from hundreds or 1000s of full nodes that also have this information. At its core, it's really no different than, you know, if you've ever used a torrenting system or anything like that, you're just downloading from peers, other people running that same full node. That's part of how that integrity of verification is ensured because you have this shared security amongst everyone who also has the same data.
Piers 04:33
So, the full node is basically I own the complete history of the ledger to date or I have in my direct possession the complete history of the ledger to date. When you say “Don't trust, verify” what is the universal things that a user or developer would want to be verifying, rather than trusting the network?
Michael 05:00
Yes, so, my balance, the history of transactions. Keeping it simple, fundamentally, Bitcoin is just what's my balance and what's the history of my transactions. There's also recently this kind of balance-gate, if you will, on Ethereum, where it's actually quite difficult to verify the balance of the Ethereum blockchain and, you know—
Piers 05:28
For ETH, specifically.
Michael 05:29
For Ethereum, correct. Whereas Bitcoin makes it very simple, where you can just one-command and you get the supply. That's a big, that's a huge reason why Bitcoin is important as well, just philosophically. So, very simply, you would want to run your full node to ensure that your balance is what the blockchain says it is. A really interesting issue behind this is, if I'm sending Bitcoin, it wouldn't be too difficult. Thankfully, we have trusted companies like Coinbase and, to be fair, we wouldn't be where we are today without them. But what if they put in a different address of who you're sending money to without you noticing?
Piers 06:09
Well, they couldn't do that. They couldn't do that because you have to cryptographically sign the transaction with your private key, in which you need to have the public address for which you're sending funds. You can't say to someone, I'll send— If I'm given an address and I submit a transaction to the Bitcoin network, a node can't then swap out that address for another address. It's cryptographically impossible for them to do because what I've done is, I've signed the transaction request with the specific information, including the recipient.
Michael 06:46
Correct, but I'm trusting Coinbase to show me the correct address that I'm sending to before I sign it. That would be a straightforward man-in-the-middle attack where swap out the UI of the address I'm sending to. Right? Back in the ICO days, this was a very common attack, where—
Piers 07:05
Right.
Michael 07:06
Yes, yes. That's when I say, once you sign and send it, which is why you want to run your own full node, you're running locally, on your computer, there's no one that can get in the middle of that and change that address, for example. So that goes into the whole “Don't trust, verify” but, since then, the industry has moved forward. Frankly, we needed this, right? I mean, we've moved— we've definitely reached a modicum of some popularity around the world as an industry and that's because it's really, truly improved the user experience. Part of the issue here is that if I'm running my own full node, great. I can handle my own browsing, my own wallets, etc, etc. I could even run a full node for my family and a full node would be more than capable of handling that kind of traffic.
Piers 07:58
What would that be data-wise? What would I need or how much data do I need to store to run a full Bitcoin node today or a full Ethereum node today?
Michael 08:06
Oh, gosh, yes. A full Ethereum node is somewhere— This is part of the debate but if you're actually downloading the entire state of the Ethereum blockchain, you're looking at a terabyte and a half, or something like that. I think Bitcoin is, last I checked, around 800 gigs or something along those lines. It's expensive to run a full node. The issue is that these full nodes, now that we have this architecture where, okay, I'm using Coinbase as full nodes, now Coinbase has to make sure that everyone can access those full nodes, part of the problem is that these are peer-to-peer networks. These are not sophisticated databases that can support web-scale applications and as a result, Coinbase might have to run two full nodes for every 1000 people, as an example.
Piers 08:57
Why? What is Coinbase doing that requires two full nodes per 1000 people? What's the load from the user that's creating that requirement?
Michael 09:12
Imagine I'm refreshing my page; I made a transaction on the Bitcoin blockchain and I want to make sure that the transaction went through.
Piers 09:21
I'm sure no one's ever done that. Refresh, refresh, refresh, refresh, refresh, refresh, refresh, refresh [laughter].
Michael 09:27
Exactly. I would say a bulk of these requests is reading data from the blockchain. Whether it's making a trade and making sure that that information gets through so that I can get to the next one, you can see— The thing is, every time I refresh, that is dozens of requests that are going to a Bitcoin or an Ethereum full node, for example. When you have 1000s and 1000s of people doing the same thing at the same time, any full node from all of these blockchains is woefully unprepared for this. As a result, these companies have fallen back to Web 2.0 solutions, which are tried and true and proven. Which is how— I'm sure, every single one of us has tried to use one of these websites during one of these cycles and the website goes down. That's because even the tried-and-true Web 2.0 solutions are failing [chuckles] because of the load, because all the data that's going in between the users, and, in the end, at the end of the full nodes that, say, Coinbase is running.
Piers 10:33
So just to break— just to really simplify this, I suppose, for my own mind. The way I think about this is the following and please tell me if this is wrong. Most people think about a public ledger as mainly dealing with transactions. I submit a transaction to the ledger and then the ledger verifies that's correct and that gets added to the state, but actually, in terms of the number of requests that come across, that's the smallest percentage part of it. Actually, a lot of things are querying state like, what is my balance? Has this transaction gone through? What addresses are associated with this transaction? What's the history of this token or this coin? All of those things are not actually rewarded by the public ledgers themselves. Like, if you're running a full Bitcoin node, you don't get rewarded for servicing 10,000 requests an hour, for updating the balance information for someone. You don't get paid for the bandwidth that takes, but that does actually happen to consume real bandwidth and have real costs. You're talking about the website analogy. That is essentially what a website is doing. A server is put up on a website that has a web address. That web address, when addressed by a browser, is being pinged. The DNS then looks at the IP address of the server. The server then returns the information that was requested by the browser and most servers can deal with around 2000 requests, simultaneous sessions before they fall over. What we're talking about here is similar, a similar problem, where you essentially have two sets of problems. You've got the validation of updates to state as one set of problems and then you've got the second set in the order of problems that a lot of people don't really think about, which is, well, there's this request layer that needs to exist to even be able to do the transactions in the first place. Even to be able to go, “Oh, I would like to send a Bitcoin transaction.” Well, to do that, you need to know what your balance is. Actually, with Bitcoin even more than that, you need to know what the UTXOs you can spend are and then you need to be able to encapsulate those in a transaction and submit them back to the ledger. All of that requires all of these requests that are not incentivised by the network natively. As a result, you often can't expect to just be able to ping any node on the Bitcoin ledger and it to respond to you with a random request for information, especially if it thinks that it's not necessarily going to make any money from doing that.
Michael 13:29
Exactly. Yes. And it really depends on the website because most websites don't even allow you to connect to your own node [chuckles]. There are some— if you've ever used MetaMask, they actually let you connect to your own Ethereum node if you're running in a home server, on some cloud, or something like that. Some websites allow you, but I'd say 99% of them just don't, just for UX purposes. Why add more of this kind of complexity? We live in a world now, where a handful of companies are serving most of the data for many of the applications that we use today, which has created, philosophically, this centralisation point, right above the core protocols, which, philosophically is a big reason we exist.
Piers 14:21
So, the ledger may be trustless, but because of the difficulty in running a full node, you end up having to interface with trusted companies, so that you can actually use the crypto that you own or use the ledgers that you want to access, which ends up concentrating that request layer in the hands of brands that people recognise and trust because of this problem of— well, you could just swap out an address or you could do something that would mean that I fundamentally end up getting my funds lost or stolen or something like that. So, we need to trust at the moment people like Coinbase and people— and other people who run— and wallets that run full nodes and put themselves out there as a trusted entity to help you access your crypto.
Michael 15:11
Exactly right. That's exactly, exactly right. Philosophically, that's a big reason why we exist. Pragmatically, it's also expensive to run full nodes [chuckles]. Going back to the Coinbase example, if I’m running two bitcoin full nodes for every 1000 or even 100,000 users, it's incredibly expensive because you're having to guarantee uptime so that my website doesn't go down. You have to have backups and just running a full node today is so expensive. I talked about the size of these, just one full node. You have to have backups on multiple cloud environments, so from Amazon Web Services to Google Cloud, to Azure, to whoever it might be, I need to be able to run backups and as a result, it's actually much more expensive to run a scalable full node infrastructure for a centralised blockchain company than it would be for a traditional Web 2.0 company because, just to talk about the scale here, one company back in 2017-2018 and even today were doing 10 billion requests a day. That's just one infrastructure company servicing 10 billion requests a day. If I had to guess what kind of an aggregate the entire industry is doing, I’d say it's probably between 500 billion and a trillion requests a day, conservatively. That's a lot of servers [chuckles] running in the cloud and, as a result, it's incredibly expensive. If I’m spending $10 million a year on the primary servers, you can expect that that same company is spending another $5 million a year on top of that, just to ensure that they have the backups ready, so that my users can access the blockchain that they're accessing. Fundamentally, Pocket's architecture, because it's distributed and decentralised completely, removes the need for that cost. This is the big thesis behind Pocket: infrastructure as a commodity. By fundamentally having an architecture that is much more cost-effective, we can provide the same service at a fraction of the cost of even what centralised entities can do, so—
Piers 17:22
Let's go into what Pocket does a bit, then. Your pitch is, essentially, all the entities that are currently running full nodes right now for their users, be they exchanges, or crypto wallets, or websites like CoinMarketCap, or blockchain explorers, or decentralised exchanges, or aggregation services, all of these entities that constantly need to query blockchain data, you don't need to pay to run your own infrastructure directly. You can instead rely on a secondary network specifically designed for query requests, which is Pocket, right?
Michael 18:10
Exactly right. One could say it's an API as a protocol if you will.
Piers 18:14
How can I— this whole “Don't trust, verify” thing, how can I be sure that what Pocket serves me is trustworthy enough versus running my own node?
Michael 18:33
Yes, absolutely. If I’m running my own full node, I’m querying that one node and since I own it, I can be sure that the data, I haven't tampered with it. The question is, if I’m querying a random node around the world because Pocket right now has nodes running from Australia to New Zealand to Moscow to Europe to the Americas, how can I trust that that data has integrity for my application? Part of the magic behind Pocket is, I’m actually querying 5 nodes at once and I could even query 5, or 10, or 20, or whatever it might be that, depending on the security, I need for my application, but, fundamentally, I have five random nodes and they all respond independently with the request. Let's say, “What's my balance?” The magic behind Pocket is that all of those nodes are financially on the line for providing good data, so, when an application queries 5 nodes and 4 come back with an answer of 15, and the 5th one comes back with an answer of 20, that node that gave some bad information is subject to be burned or slashed, or their money deleted by the protocol. Fundamentally, that's at the protocol level, specifically. That's how you can make— you can get guarantees—
Piers 19:59
At the Pocket protocol level.
Michael 20:01
Correct, sorry. Yes, at the Pocket protocol level. That's how an application can get guarantees on the integrity of the data that they're getting. Effectively, you can ratchet up the security by increasing the amount of nodes that you're querying at any one point in time.
Piers 20:17
All right, so to break that down a bit more, there's a protocol, the Pocket protocol that all nodes that want to provide this query layer, this API for blockchains to end-users and companies, that all of these nodes are running. Much like a consensus system, like Ethereum or Bitcoin, there is a way in which these nodes can agree on whether or not someone is being dishonest and punish that person for doing that. So, everyone is running— Is it a blockchain?
Michael 21:01
Yeah, Pocket is its own independent blockchain. It's meant to solve this one problem really well. It's not a smart contract platform. It's an application-specific blockchain meant to ensure redundant, cost-efficient infrastructure for your applications.
Piers 21:20
I suppose there's a load of questions that come up behind that, which is, how do you guys deal with throughput? If I've got many millions of requests per day or per hour, how do you make sure that the network is constantly in sync and that dishonest actors are caught and punished quickly enough?
Michael 21:50
Absolutely, yes. What's interesting about Pocket is that, while it is a blockchain, it actually stores as little as possible on the actual chain, so, when you're explaining how the integrity of the data is ensured, it's a relationship between the application and the nodes it's querying. It's a signature game, where the application signs with the Pocket private keys, saying, “Hey, I'm requesting my balance” and just as a normal web-scale service, the applicant or the node can then respond immediately, “Hey, here's your balance.” The trick is that nodes don't receive the reward until a few hours later. What happens is, all of these requests happen off-chain and all the node does is, submit one transaction to the Pocket blockchain saying, “Hey, I did a million requests in the last hour.” That is very, very little data that actually gets submitted to the Pocket blockchain because it would just be completely infeasible if [chuckles] a node was submitting every single API request. We've designed Pocket to scale to, likely, quadrillions of requests a day and if nodes were submitting every single one of those transactions to the Pocket blockchain that would just be— That's impossible. That's quite impossible, so, the node just submits one simple transaction and that's proof of the game between the application and that individual node. What happens is, a couple of blocks later in the Pocket blockchain, that transaction that the nodes submitted gets proven through a set of cryptographic— through a zero-knowledge range proof that is native to the Pocket blockchain, saying, “Hey, this node did the work that they said they did.” If that node, maybe, submitted one extra transaction or said they did something with someone that didn't actually happen, what ends up happening is that that node gets the Pocket that they use to access the network, firmed or slashed, with it native to the protocol. What happens is all this work happens off the Pocket blockchain and what's great is that that gets compressed into one really quite small transaction, once an hour, in the Pocket blockchain. That's how we're able to scale so greatly. You mentioned consensus and it's actually not the nodes reaching consensus. It's actually the nodes reaching agreement with the application and the application actually saying, “Hey, these five nodes have been consistent with the information that they sent me.”
Piers 24:27
“They've all told me the same thing.”
Michael 24:29
Yes, exactly.
Piers 24:30
So, you're actually pushing the decision on whether or not nodes are being honest or dishonest onto the application rather than onto the network itself.
Michael 24:44
Precisely.
Piers 24:46
Very interesting. Okay, so, why is using Pocket cheaper than— I suppose, let's have a little talk about what currently exists as competing solutions. I think the main one that most people will be familiar with is Infura from Ethereum, where you have this Infrastructure as a Service. I don't have to necessarily actually spin up— I don't have to instantiate in AWS, my own instance of an Ethereum node and get it all synched up and everything like that. I can just pay for some instances on Infura that are my instances that I can then go and query if I want to and I can change how they function if I want to as well, but, ultimately, I can guarantee a level of service for myself via that mechanism.
Michael 25:40
Yes, exactly. It takes 30 seconds to sign up for a service like Infura and they have been a core piece of the Ethereum ecosystems capacity because it's very easy and quick to do it. But if you think about the architecture of a service like Infura, to operate at the scale that they are operating at, which is in the 10s of billions of requests a day, they have to use cloud services like Amazon Web Services, for example. When a service like Infura uses Amazon Web Services, they are paying rent to AWS. If you've ever used a service like AWS as a company, it's not uncommon to have a server bill where you're like, “Whoa, where'd this come from [chuckles]?” Because, frankly, it's expensive and the skills you need to optimise these things are few and far between, to be honest. That's the first piece. You already have a middleman between the middleman [chuckles], if you will, where you're running these services on— To operate at that scale, Infura can't justify buying a data centre or multiple data centres, having a global presence in Europe or in Asia, in the US, etc, etc. It makes sense to use a service like Amazon Web Services. That's the first piece. They're already paying rent to AWS. The other piece is like I mentioned before, Infura is bearing the cost of running these full nodes as well. Since these full nodes are so bulky and huge now, where an Ethereum archival node is on the order of one and a half terabytes, it's another $500 a month to run an archive on that. When you're running dozens of them, that gets very expensive very quickly. Then, when you're having, at this point, tens of 1000s, hundreds of 1000s of people refreshing their wallets or accessing some DeFi protocol, that's a lot of data that they're having to pay for. What ends up happening is that it's fundamentally inefficient and expensive for them to operate the service and that cost is borne by the developer paying for the service. So Infura, as a traditional SaaS business, Software as a Service, you pay a monthly fee and they rate-limit the amount of queries that your application can do. When your application reaches a new tier, you're paying— you might pay 500 bucks a month, $1,000 a month, and then that's your business model. The difference that— the major difference in architecture with Pocket is a couple of things. Oh, and one more thing, sorry. To ensure uptime for the service, Infura also has to have these backups, which, again, I have to have multiple full nodes to serve one user, say, one-and-a-half-full nodes, actually, to service a user. So, if I'm spending $10 million a month— oh, sorry, a year on infrastructure on my primary set, you can add about $5 million of additional costs, just to ensure 99.9% uptime for my users. That kind of cost structure is borne by the developer building whatever DeFi application. There are a couple of differences in Pocket. One, because we have hundreds of nodes already running in the network, when one node goes down, there's hundreds ready to replace it. So, there is already that extra cost of the backups of what we call redundancy is gone in Pocket because it's integrated into the protocol. So, a server, a node runner, in Pocket doesn't have to run a backup because there's already an entire network there backing them up. If their internet goes down, lightning strikes, whatever it might be, there are hundreds of nodes ready to replace it, removing that cost from the actual node itself, from the infrastructure provider, so already that cost has gone. The other important piece is that in time, you can actually think of Pocket more like a proof of work protocol in this respect, like Bitcoin where you've seen people, you know, switch from running, you know, full nodes in their home mining, mining Bitcoin in their homes to full data centres, right, or people purchasing massive data centres all around the world to mine Bitcoin because that's the most cost-effective way to do it. In Pocket, the architecture it's inversed, where instead of people running these nodes from their home, currently, they're running them from the cloud, actually, so people running them on Amazon Web Services, Google Cloud, whatever it might be. In Pocket, it's actually much more cost-effective to run it out of a local data centre, completely removing that need to have to pay rent to Amazon Web Services, for example. So, it's much more cost-effective for me to buy my own server and spend 1000 bucks on a good server and use that to effectively mine POKT, as opposed to paying Amazon Web Services for it. So those two kinds of architectural differences are what, frankly, make Pocket significantly cheaper to run and significantly cheaper to access for developers, specifically.
Piers 30:46
I think that the thing that someone might level at you there, the first blush on that is, well, with Infura, I've only got one backup, so I'm only paying for one backup, but with Pocket, I've got hundreds of backups, so that sounds more expensive. But the way to actually think about this is, it is shared infrastructure. In Infura, I have one piece of infrastructure per client, which means that I can have 1000s and 1000s of nodes, as a result, because I've got 1000s and 1000s of clients, but the usage of that is very uneven. Some of those will be maxing out their requests and all that kind of stuff and others of them won't be, and there's still all of these redundancies that sits behind here. What Infura is doing is basically going, “Well, instead of having one dedicated client with one dedicated backup per customer that needs this query layer, what we're doing is we're basically saying, well, let's have a decentralised network of hundreds of nodes and the query requests will be spread across this network,” so that you end up getting this very neat auto levelling of load across the network. That means that all nodes in the network are being used at approximately the same level of capacity as all other nodes.
Michael 32:16
Exactly, right. Exactly, right. As a result, you don't have to pay for backups, for example, I know roughly how much work my node is going to do since, as you said, the protocol load balances or splits the work up evenly across the entire— all the nodes running on Pocket.
Piers 32:33
So how does Pocket's security actually work? You’ve got a proof-of-stake algorithm? What was actually happening there? How does the POKT token work?
Michael 32:42
Yes, so, Pocket, economically, you want to conceptually think of, actually, more close to a proof-of-work blockchain because I get paid for every request that I do as a node. But the way that the state is protected on the chain itself is through proof-of-stake. Every note that is staking in Pocket is also contributing to the security of the network by participating in proof-of-stake consensus. The way the rewards were split up is about 89% of the work that I do, the reward goes to the node that did it, 1% goes to the proof-of-stake consensus block producer, so it's very similar to when I'm a Bitcoin miner, and I get chosen to create a block. The difference is that the Bitcoin miner gets the full block reward. In Pocket, the chosen block producer gets 1% of the block reward, in this case, and that is— well, it secures the integrity of the chain as a whole. Then the other 10% goes to a DAO that gets managed by the protocol, and so on, and so forth. Fundamentally, the way that the state gets protected is through proof-of-stake. We haven't invented our own proof-of-stake algorithm or anything like that. If you've heard of Cosmos, they use a consensus mechanism called Tendermint. That's something we're seeing that at this point, dozens of protocols— actually, the Cosmos ecosystem is growing quite, quite rapidly. But, for us, we wanted to use the most well-tested consensus mechanism at the time and that was Cosmos for us because they had already launched a blockchain and had seen some smoothness, and success, and the stability of the protocol. So—
Piers 34:35
I certainly wouldn't say it's the most tested consensus algorithm, but it's certainly got some interesting new features. Obviously, the Ethereum consensus algorithm has had more extensive testing than the newer ones.
Michael 34:54
Of course, yes. Ethereum as proof-of-work, yes. Proof-of-stake chains are still a relatively new concept, so, the longer these are— At the time they were the most well-tested for what we were looking for-
Piers 35:07
Yes, absolutely.
Michael 35:08
-because they've done a really great job in building this in a way where many protocols can use the same consensus independently.
Piers 35:17
Yes. Yes. Yes. With regards to the— Just take me through some statistics of your network at the moment. How many nodes do you have?
Michael 35:27
Yes. We launched mainnet on July 28th and right now we're hovering right around 190-200 nodes on the network. This is a global set of nodes from Moscow, to Australia, to the Americas, and so on, so forth. They, today, are serving somewhere between 1 million and 2 million requests a day, which is pretty incredible. The fact that we've got this blockchain that is coordinating infrastructure at a global scale, trustlessly [chuckles], it's actually quite— just remarkable to see. So—
Piers 36:04
It sounds really awesome.
Michael 36:05
We see it as a marketplace. Developers pay for Pocket to access the network and nodes also pay for Pocket to have the right of doing work in the network. You've got a kind of circular two-sided marketplace here, where the inflation of the network is completely dependent on the work that gets done. You have both sides access the network for their own reasons, but yes, it's been really great. We support Pocket natively, of course, so we have a couple of Pocket applications that are, of course, running on Pocket, like a block explorer, and a wallet, and that sort of thing. Then, we also support Ethereum today. I'd say 80 - 90% of our traction is going through Ethereum, though one important piece about Pocket is that it's blockchain-agnostic. We're about that middleware you can just put in front of any full node and quite simply provide access and incentives for any other native chain.
Piers 37:04
In terms of the usage so far, what kind of applications have you guys started to work with and what kind of request data are you dealing with at the moment?
Michael 37:18
Yes, so our bread and butter are our wallets and block explorers. In fact, you could put in a Pocket URL in your MetaMask today and access the network. By doing that, you're actually providing an incentive for people to run full nodes for Ethereum, which is pretty, just pretty impactful actually.
Piers 37:36
Do I need to have POKT to do that?
Michael 37:39
No, you don't, actually. The way the protocol is designed, instead of paying fees directly to the nodes, like you would a SaaS business, developers stake POKT once. By staking POKT once that is what gives you some allocated throughput or access. So, instead of paying $50 a month for 100,000 requests a day, I might stake $200 worth of POKT for the same access, as an example. The key piece with this MetaMask URL is that we as a company are staking on your behalf and because of that design, we can actually abstract the entire need for users to ever even know we exist at that point, which is really impactful, harkening back to Coinbase, it's important for that user experience as well for us to reach some sort of success here. So—
Piers 38:31
What would I expect to see as a difference in experience, from the point of view of a user, if I go from using the current MetaMask query nodes, which are provided by MetaMask, to selecting the Pocket network as the query ledger? What would I expect to see as a difference to my user experience?
Michael 38:54
Yes, you wouldn't notice much difference at all. We're talking on the order here of hundreds of milliseconds. One of the trade-offs, to be fair, is you are accessing a global set of nodes on Pocket. One of the efficiencies of a centralised system is that they can say, “Hey, look, I'm in Australia, let me provide a server that's closer to you so that you're not taking forever to load something.” The difference here is, where you might get a load in 200 milliseconds or a fifth of a second, Pocket might be at 300, 400, or 500 milliseconds, as an example. But in the grand scheme of things, depending on the application, at that point, it's negligible in terms of the speed. That is because you're accessing a global set of nodes. That said, what's interesting about Pocket is that we have hundreds of nodes running today. We've designed the protocol to, frankly, have 10s of 1000s of nodes, and once we reach a critical mass of nodes, we'll be able to sort by location. Imagine Pocket Americas, Pocket EU, Pocket Asia, Pocket wherever it might be. You can actually sort by location in the future as well. Of course, these are the trade-offs we've made early on, where an application might be happy to cut their server bill by 20, 30, 40 grand a month for that trade-off today. That's the big difference right now.
Piers 40:23
Super interesting. Okay, so if people want to get involved, how can they get involved? What can people do right now on the Pocket Network and who do you want joining, who do you want to talk to?
Michael 40:34
Yes, at this point anyone can contribute to Pocket by, for example, if you're browsing DeFi on a daily basis, we've got a blog post that you can add the— it gives you— it'll take you 30 seconds to add our MetaMask link to your daily browsing that immediately contributes to more people running full nodes at a lower level. Our community is quite strong on our Discord. If you're keen on learning more about the protocol, contributing yourself, either as a developer or node runner, and whether you're technical or non-technical it doesn't make a difference, we've walked people through setting up their own nodes regardless, so I’d say our Discord, which you can find on our website or through our Twitter, which is @POKTnetwork. This is where you can definitely keep up with what we're doing.
Piers 41:23
If they want to run a Pocket node, is that something that people can do?
Michael 41:30
Absolutely, yes. That's what's really interesting about an open-source protocol like Pocket because the secret sauce or competitive advantage of these kinds of centralised infrastructure providers is, they are closed source infrastructure setups. What Pocket is doing is, actually, breaking this up and, frankly, making it easier for people to run these sorts of infrastructure. We're not quite there yet, but in the not-too-distant future, you'll be able to run your own full nodes with a couple of clicks. That's a really interesting thing about how these open-source incentives work. We can collectively gain economies of scale through this open-source software which is really impactful. So yes, if you want to run a full node I’d say come into our Discord, ask some questions, we'll point you in the right direction, either way.
Piers 42:24
That's awesome. Michael thank you so much for coming on the show. It's been a real pleasure talking with you.
Michael 42:29
Thank you for having me, Piers.