Making DePIN Work for Developers of Web3 Consumer applications - Ben Biedermann | Raid Guild PORTERS
ETH Belgrade Community·Mon, Oct 7, 2024, 12:00 AM
Transcript
thank you so hello everyone um oh yeah slides are up all right uh I want to speak about the porter RPC Gateway today um and how we are making RPC gateways work for web 3 developers now RP what I don't know who of you have used an RPC hopefully some of you um so we're going to dive a bit into what an RPC is then what we should care um and then we'll shift more into the deepin side of things um and lastly we'll um talk a little bit about our take on how we make RPC work for web3 developers now I came across when I was looking at RPC um and what you know in the ethereum or web three world how they do it I came across like the people and the papers that you know designed rpcs so my question now what does a printer and ethereum have in common anyone struggled getting something to print at like a a printer they they weren't previously connected to well chances are that it was because of RPC because printers and ethereum do use rpcs in order for you to not have to run a node to participate in the network so long story short a remote procedure call connects two systems that don't know anything about it that don't share memory that do not communicate other than over very narrow socket and this is a problem but it's also an opportunity because you don't have to bring networks very close together or you know applications using the same memory but you can have two entirely separate separate systems that can now communicate so probably a more common example um where you would encounter that is when you add a network to your metamask so you would basically that actually works uh you would basically um put your RPC in here and you have to do this because your web threee wallet your client doesn't know anything about the state of dection it it doesn't use restful API or anything it's just you have to actually manually put it there now why is that a problem and especially if we go back why is uh I think the presentation crashed can you maybe go on full screen again okay anyway um when we look at the the RPC aspect in the back so actually the the VB address then you can see that you're relying on nosis chain.com so if nosis chain.com is lying about the state of the blockchain um you have a problem so now we don't want to lie today and therefore we have a single source of Truth now back up and running um anyway why is this a problem so the problem is that you have or that you introduce a single point of failure so you have your RPC service that kind of sits in the middle between the blockchain and its peers and the DAP you're using or you know the client it can be your metamask wallet it can be any other wallet it can be your dab that you're building and that you really want to work because when you launch you better make sure that no one is lying about whether your transactions are going through or not so this can be alleviated by decentralizing the men in the middle the RPC service and the RPC service is there because like if you are a consumer or a DB Builder you want to focus on your use case you want to focus on getting your job done you want to focus on sending that money to a friend but you don't want to run a node and essentially you have to run a node or you have to rely on RPC services in order to make that call make that relay just post that transaction and then also know when it's completed so I don't know who of you has been around like two years ago uh metamask and consensus updated their terms and conditions and their privacy policy and all of a sudden started linking IP addresses with web three addresses so when you have a client that actually shouldn't and doesn't know anything about the state of the blockchain and then you have infura as like an RPC provider and they are both run by the same company all of a sudden it's not so decentralized anymore so it actually poses a risk to to trust that RPC provider to trust um that client and to trust that they're not one and the same entity so this is where deepen comes into play and like the person speaking before me he was going about iot devices and like all this fancy stuff but this is a side of deepen that might be a bit more boring but something that you actually encounter daily and not when you are on a train and you see like a weird NFC kind of symbol saying that you know there is an IT device so we also heard a bit of like a background about what deep in is but essentially deep in our cryptoeconomic systems so you have like a mechanism that organizes different actors that are predominantly interested in their self-interest um and you bring them together without them having to trust each other and introducing a modularity by having several actors that allows for the system to adapt to adopt and basically to not have to rely on like one actor or like you know contractual like obligations or or constructs that that put everyone in place so when we speak about RPC networks so different peers that are organized according to a consensus mechanism that programmatically come together to find an agreement on what should be relay to a given Network or should be sent back based on a request that was made um there are a few but we have like we have been working with pocket Network um and they call the process of like basically posting trans actions from a client to a network and getting data back aay and coming together and and making that like having nodes doing this together they call relay mining um and they contrast like their model I think they have a couple thousand nodes all over the globe uh there are some well some weak spots um predominantly in Africa and Latin America where like not so many nodes are located um but overall they have several th000 noes compared to maybe 50 or 100 um like a middle to like large RPC centralized RPC provider has running for for any G Network and and this is fairly optimistic so um pocket Network brings together all these thousands and thousands of notes that basically agree on what should be sent to a client to a Dap um or what should be posted on a network so in any like for any like relay to be propagated you need at least 24 different parties coming together and 24 is like by default much larger than what you what you would have if even you were running your note right um so there is just one problem by having a network on top of a network again anyone wanting to post to that Network needs to be part of it so essentially what what you need is you again need to be a participant and that's an issue so that's why pocket introduce something what they call gateways these are essentially re centralizing points um or points of Confluence where like a consumer or you know a builder can choose between any of them but they essentially would get something what they would expect as like what an RPC endpoint looks like um so we are basically describing shift from centralized node as a service providers back to like a decentralized network acting as one but being many so why do we do this um why do we work with pocket because it enhances privacy it you know maybe offers anonymity for someone who's super careful uh but it definitely offers sity and it enhances your availability because you can actually tell the network well you know I'm located here please pick the closest node or the closest nodes in order to make that relay so this is where we come into play pis um so pis it's basically an RPC Gateway so we we sit on top of the pocket Network and kind of bring together like the strength of the strength of the network but making it more accessible um so this is an authoritative take on how you should do RPC gateways or desized RPC networks and it's it's maybe necessary to make a distinction so on the left hand is it yeah on the left hand side we we have like you know rough stack so like the the porter stabs it's somewhere in between then you have a DB that you like you you build and you have por where you can configure your RPC gate RPC end points then there's pocket and then underneath you have a DLT or a blockchain um depending on what you want to call it but essentially data moves up and down the stack and now you could say well but you know Portis seems pretty centralized I mean you're you're sitting there and like you're you're kind of guarding and you know that's a fair critique um but when we actually look what decentralized mean means we need to distinguish it from distributed networks so underneath like you have distributed Network that can be pocket that can be etherum main net um and then on top of it you have decentralization because like one of the let's try this again hopefully it doesn't crash again so uh you have like one of these thicker um nodes and that is essentially what is like the the dark brown node here meaning that we decentralize on top of a distributed Network and I think this isn't appreciated enough it isn't appreciated enough that decentralized doesn't mean the same as distributed that there is a distinction yet at the same time they can very well integrate and work together so essentially we are a Confluence on a decentralized network that uses or that relays data to a distributed Network essentially ethereum or other blockchains now why do we do all of this why do we need to introduce yet another layer in between um aren't there already enough layers well you could argue yes there are but also you know we want to reach more than like the people here and this means that we need to get a lot more like what it used to be more easy faster you know more more seamless and you know corporations and consumers do like web too like they do like the experience it's something they are familiar with so we need to make an effort to make it more seamless and at the same time for developers working in the space you don't want to always use your credit card I mean let's say you're working for a client uh you're you're building this stab and then you you hand it off at some point and you have to put your credit card in in order to you know make this fly and when you or if and when the stab goes live but you're still in the project like it's your credit card info and it's your relays you're going to pay for it whereas with Porters it it's just as simple as buying a voucher meaning a token and redeeming it anyone can do this anyone can airdrop you this token and you can pay for it there's like no data no personal data linked back to you other than maybe your IP address um there's there's nothing that stops you from going out getting a grand and and putting it directly into RPC relays or credits without having an additional hop or anything between um so this is how it looks um what we have built so roughly we have like the user and the user might be a misnomer essentially these are the developers uh we have the portal we have the finance aspect of it so this is like the parment smart contract um and kind of interfacing with the actual RPC that is in the bottom right corner um there are a couple of databases and actually the challenge we faced were like making them all talk to each other and making sense of the data they they were getting and you know rate limiting at the correct point and time rate limiting um to the extent that was desirable and also caring for developers because we went out there we looked at what what people were building and apparently developers in we 3 don't like like backends so what we saw is that like many applications essentially were having the the secret that is required in order to access an RPC endpoint was was in the client sighted software code so not not really secure so so we had to take this into account which essentially led us to and I don't know yeah which essentially led us to introduce rules so instead of giving like a vanilla RPC endpoint um we introduced the concept of apps meaning that an RPC endpoint is just one aspect or one way to interfacing um and you can be way more granular about how you want like these RPC relays to be governed so essentially you could think of Porters as something like Alchemy but more decentralized uh we we don't like to call it this way but apparently uh it's what people understand um and to that end we are thinking about something that is called portals so like the porters are governing the portals and this is essentially um in order to to serve developers coming into web 3 that might have like a web to background so we're current working together um with a project called token name service so essentially they are the decentralized alternative to something like coin gecko or coin market cap and together we are building a token API which essentially is a restful API so it's super easy to integrate it is not as decentralized but the data that is underneath doesn't come from like a centralized entity it doesn't come from coin market cap or coin but it actually comes from like a an army of contributors um putting in this data and and making it available so essentially what we're doing is we're just making it more easy to to access rather than you know centralizing the entire stack so this also helps by you know Bridging the Gap between web 2 and web 3 by you know just mixing and matching it how developers need it and want it um in order for consumers to be able to use it the most seamlessly um so yeah if you want to try it out por you get way to three um but I mean basically we're looking for feedback and we're looking to to see how we can you know slice it up differently or or make it work so that it's not just pocket or or pors but you know web 3 at large that benefits from mixing and matching web 2 and web 3 um under the premise that we are decentralizing and relying on nodes that are not run on the server but by enthusiasts with the dep note all across the world thank you very much hi okay all right um yeah so the big question is so you touched upon this so you're sort of have you have this decentralized network of RPC basic no providers and then you're sort of centralizing it in this Gateway so is there anything stopping Porters from having the same privacy issues as in fura for example so what what I'm asking is can Porters in theory still you know sell data later on well I mean theoretically yes of course um and but you need to look at what kind of data Porters actually get and you know we we had this problem um so we we do want for example to allow users to have an invoice right um because for for many of our people for many of our users it's important that they can you know like deduct these costs like from their revenue in order to you know not pay tax on you know cost they they spend so we we wanted to you know make this simple invoice and we realized well actually we don't have like a lot or a lot of data so um when we're thinking about r or you know valuated tax GST we we didn't have any of this so essentially what all that Porter has is something that you could from the blockchain so we have a payment token that essentially is just bought to be burnt um to facilitate payments you can also like you know directly redeem or or swap on the spot um and there's this transaction ID the identify and the IP address but like there is nothing more thanks anyone else with a question question no all right thank you so much thank you so much
Automatic transcript — names and jargon may be misspelled.