New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Pocket Network V1 Hello Block Daniel Olshansky

Ethereum DenverSun, Oct 9, 2022, 12:00 AM

Transcript

all right uh before i get started i do have to say adrian love your hair kind of hard to follow up on okay uh with that being said hello everybody my name is daniel shansky i'm a protocol specialist primarily focusing on consensus work at pocket network and today what i want to do is talk a little bit about the design decisions that went into pocket network v1 which is the next version of the protocol and give you some insight into the design decisions that were made and headway that our team is currently making under uh right now so firstly here's a high-level agenda of what i want to cover firstly i'll talk about what pocket network is then i'll compare how the v0 stack compares to the v1 stack v0 is out in the wild and v1 is underway as we're speaking then i'll talk about why we're moving away from tendermint which was a very interesting decision and a lot of interesting details that we can cover there and then i'll give you a very high level idea of what we're doing with the consensus of the utility modules because there's a lot of really cool stuff that's happening there as well that i'm very interested very excited to share with you guys so if you don't already know what pocket network is it's a web 3 infrastructure middle pro middleware protocol that provides a decentralized multi-chain rpc layer that was a mouthful but what does it actually mean so if you're if you're a dab developer and you need to access and read and write data to a blockchain of your choice you have a few options you can you you can either run your own node locally uh on your own server behind some authenticated endpoint or you could potentially be using some sort of centralized provider what pocket network does is solve that problem there's a lot of articles and conversations and people discussing on various podcasts how we have this beautiful decentralized web 3 world behind a centralized web 2 gateway the way pocket network works is as an app you stake some pocket our neighbor our native cryptocurrency token and then you start making requests that we normally would with any other option that i just mentioned earlier um on the back end our network matches you with a few nodes so whether you're working with ethereum or solana we match you with a node that supports that blockchain forward your request and get your response ultimately what that means is you get a decentralized secure service regardless of whatever protocol you're building your app on even more importantly and i'll touch on this in a moment is the incentive mechanism that we have for node runners to be pocket validators as well as run full nodes of other blockchains in the crypto ecosystem so now that you kind of know what pocket is where is pocket so pocket we have nodes all around the world and as of this week we're handling more than 2 billion relays a week with more than 2 billion release a week supporting more than 40 different blockchains on our network and we recently just crossed the 30 000 node mark to put that number into perspective bitcoin today only has 15 000 full nodes on their network we have twice as many and we're supporting many different blockchains to make sure the developers are able to get the best service as they're building their app [Applause] but what's even crazier is not where it is but where it's going so if you look at the number of active nodes it's three thousand it's the year-over-year increase is three thousand percent if you look at the number of average relays it's up five thousand percent year over year but how are we getting there like there's so many nodes so many relays what's the real incentive well what's driving all of this growth is that our rewards it's financial incentive for validators to run pocket nodes alongside other full nodes of other blockchains and applications get a very high quality service at a cheap price by staking pact which is how we also reward the node runners in the network so now that you know what pocket is and where it is and where it's going if you're running a pocket node on your server let me ask you what's in your wallet no no what's in your pocket guys well it's actually very simple i can tell you what's in your pocket what's in your pocket is uh it's an abci application and all that means is that we're built on top of tendermint and we use the interface then tendermint exposes in order to leverage their consensus engine along with their peer-to-peer and persistent slayer so the only difference that we have from other applications built in the cosmos ecosystem is the fact that we had to fork tendermint a couple of years ago the reason we did this is because we had to customize the leader election protocol we had to make some customizations to the persistence layer so that our node runners have more efficient usage of their resources and we had to make some customizations specific to the utility of the pocket protocol so what's in your pocket is a forked tendermint version from two years ago of course we've been backporting some changes of course the abci application that makes pocket what pocket really is and all the other blockchains that you choose to support on your node so there's more than i believe that we have more than 40 nodes right now but you can support whatever subset you want and here i have harmony ethereum and polygon so the network is growing the numbers look great and everything works so why should we be changing anything now well cosmos sdk and tendermint was a great way for us to get bootstrapped when it was a small team with not a lot of runway and there was no product market fit we really had to learn what are we building why are we building it and how do we build a community around it and now that we've passed that stage and the team is much bigger and we have more runway we're thinking ahead we want to be able to support an uncapped number of validators support trillions of relays a day and not sacrifice any security or any decentralization while doing so while still providing the fastest latency possible for applications all of this sounds great and it's exactly what we're thinking about as we're specking out v1 now one of the other big things and i'll dive into more details about this in a moment as to why we're changing things is we are hitting real scalability issues as you can see on the screenshot this is from the tendermint docs where it was built and designed for 10 000 validators at most this was okay three months ago but today we have 30 000 and we really are hitting the limits of what tendermint was built for so that is why we're changing things but we're not recreating the wheel from the ground up we're really learning a lot from how temperament was designed specked out and we've taken a lot of inspiration from their engineering efforts v1 is split into four core modules we have the utility module the consensus module the peer-to-peer module and the persistence module i'm going to touch a little bit on the details that are in utility and consensus since that's where most of my work lies but it's worth mentioning that there's also a lot of interesting work that our team's doing on both p2p and persistence in addition even though we're building everything in-house it doesn't mean that we're recreating everything from scratch we're we've been doing a lot of research looking at peer-reviewed formally verified literature and we're taking all the bits and pieces from different places customizing them to our needs and that is how we're speccing out pocket v1 the other really big benefit from doing things in-house is having really tight inter-module integration so we're using literature that was published in the last couple of years but we're able to optimize everything for pockets specific use case the one big thing you see here is we no longer have tender mid and cosmos in our stack and what i want to say is even though it's not on our roadmap right now it doesn't preclude us from being ibci ibc compliant in the future it's just another protocol it's just another interface and it's something we can potentially support in the future so i already touched a little bit about the scalability issues that we've been hitting with tendermint but leaving such a mature and battle tested framework with such a large and growing ecosystem is not an easy decision to make and we discussed this extensively and i did challenge this as well within our team but as you will see shortly this really does make a lot of sense now when i wake up in the morning as a consensus engineer working on sites working on sexy and fun things like safety and liveness is exactly how i want to spend all of my time but when i recently did a deep dive into the tendermint code base the amount of engineering effort they weighed that went into something as simple as state sync is immense it's something we take for granted it's something that's going to require a lot of work but it is still something that i'm that we're going to be able to do and it is a cost that we're willing to take now the reason we're doing this as as you can see in this tendermint in a nutshell info diagram is we want to modify the consensus algorithm so it's easier to understand and comprehend we want direct access to the mempool we want to modify the leader election algorithm we want to optimize everything for pocket specific use case for all of the reasons i mentioned earlier in terms in the presentation and if we keep trying to fork tendermint and merge things back in and keep and have all the support while working on a very large uh mature code legacy code base this is simply infeasible so now that we're moving away from that consensus protocol what were the considerations that we took into our new consensus protocol well firstly we had to decide do we want probabilistic finality or immediate finality like many other proof of stake blockchains especially if we want to remain ibc compliant we need immediate finality and this is a pretty easy decision what this means is that we're going to be ruling out nakamoto consensus and we have to stick with byzantine fault tolerance there's a lot of different bfd algorithms out there and the reason i have three different charts all basically showing the same thing on the board is because in different papers depending on the assumptions that you make and the lens through which you view them and how you test them there's all the different complex you have different forms of complexities associated with each bft algorithm however they all point to one thing they point to the fact that hot stuff is one of the leading bft algorithms out there in almost every single way it has linear complexity it is responsive which means that it moves at the speed of the network it it's okay it has learning complexity it's responsive and it's very easy to understand and customize as you will see in a moment so now that we know that we want to go with the hot stuff bst algorithm what else are we going to do so we take basic hot stuff basic concept is one of the variations of the host of algorithm which was driven by the libra dm project we're taking cryptographic certifications cryptographic sortation from algorand which essentially gives us a verifiably random leader election algorithm in v1 of pocket network and one of the other things that we need is a distributed key generation and threshold signing library we're still exploring a few different options from a few different frameworks but we're currently leaning towards using frost which is being researched by the zcash foundation now you take all of those different ingredients you mix them together and that is how we serve you hot pocket consensus it is hot it is blazingly fast and that's what happened to me when my hair caught on fire while working at home [Applause] so i'm not going to dive into all of the details of how basic hot set actually works but what i want to point out here is it's so simple it's linear it there's no more meshing normal no more nil voting no more gossiping it follows a star linear a star pattern with linear complexity composed of four rounds that is very easy to reason about if you just sit down read through a paper and spend a couple hours on it however after jumping and looking at the research looking at all the details this is when theory expectations started meeting reality and what happened is that at the time that the public that the paper was published there was no good threshold signature library out there and i was wrecking my brain over this trying to understand what is going on the reason this is a problem is because threshold signing and distributed key generation each takes several rounds of communication throughout the entire network what this means is that you would take the linear complexity of the algorithm and make it quadratic and this is where the power of building your own blockchain reactor and your own consensus algorithm from the ground up really comes into play this diagram is just for illustrative purposes so don't take all the colors and the arrows as a scientific proof but what i'm trying to show is that when you build things in-house with your own consensus algorithm we can leverage this linear path start pattern to disseminate information throughout the entire network without taking the cost of quadratic complexity so whether it be for verifiable verifiable leader election or distributed key generation or any other metadata since we already have that dissemination of information throughout the entire network we can just tie additional metadata to every single step and the entire network will know about it and that is hot blocking consensus now jumping quickly into our utility module uh there's a lot going on on this slide but what i kind of want to say is the waste the way things work right now is that you have a pocket validator or servicer which essentially relays requests from the application to the respective blockchain that they're hosting what this does is it solves the problem you have a decentralized rpc infrastructure we have a really good economic model where basically all of the validators are incentivized to support as many blockchains and provide as good of a service as they can and there's a lot of really novel zero knowledge proof work that has proven itself over the last couple of years the big problem with this is that there's no way to guarantee on-chain sla so this is where the utility module v1 comes in the big thing that i want you to note is that the difference between v0 and v1 is a little fisherman at the top right what the fisherman does is periodically during a session of servicing relays continuously samples the servicers that are replying to the app's requests what it does is checks for consistent consistency data integrity and latency and then basically takes a report card and posts it on chain regarding how well each servicer is doing so in v0 we have inflation that is based solely on quantity in v1 we have pocket inflation rewards that are based on both quantity and quality and if you have ever built a web 2 service you've probably seen the four nine guarantee the four nines sla guarantee from aws or gcp or azure what we have what we have in pocket network is an on-chain sla which pretty much says that you get rewarded and your service is a function of how well you're doing and how quickly you're doing and i don't have too much time to get into the other details but on the bottom right here you see a diagram we can compare pocket v0 not v1 to some other centralized services available today and we're not only competitive in the p50 and p90 latency but we're in fact doing better while not sacrificing for decentralization and being a multi-region multi-crown service for the ground up last slide one thing i really want to say is that i've been following pockets since the early days but i officially only joined uh three or four months ago after having the privilege of joining of going to their offsite in mexico so far this has been one the best experience i've ever had and most of the work that i presented here is of this team that you see here some people that you don't see in this photo and the community that's involved i've really never been part of such a small and motivated team where everyone is so excited and passionate to bring the true vision of web 3 to fruition where everyone is both challenging each other every single day is supportive of each other every single day and i still wake up happy every single morning knowing that this is what i do full time so if any of this intrigued your interest follow us on twitter join us on discord or just come say hi to our team throughout the rest of the conference thank you

Automatic transcript — names and jargon may be misspelled.