Rémy and Yorick talk about using Infura or any similar provider for a staker after the Merge

Transcript

hello everyone welcome to another talk uh by eve stalker uh my name is remy um i'm part of the east taker community and i'm joined um by joric or torsten hello yorick hello there how you doing today i'm doing great awesome today we're going to talk about uh the merge some of the implications with the merge in relations with the public infrastructure providers and one of the most popular one is called infura um so if you've ever heard of infura it's this huge um infrastructure provider by consensus it's used by metamask it's used by a

bunch of other people but it's like the most popular one there's a bunch of other ones too but there's some changes that are coming with the merge and we'll talk about them that will impact how people especially stakers are using these providers um and in different ways and we'll talk about all the different ways that goes with that so let me go ahead and share my screen here just so that um people can have a quick look there we go all right so first of all let's talk

about all of these providers so you can see here there's a few of them um and this is like a popular website that lists uh some of them i've used in the past in fira i use alchemy i don't know um yorick if you've used any of the other ones um use quick note i haven't used i think i've used anchor don't think i've used any of the other ones yeah and so like um if you're using one of these providers um as a staker you might need to tweak some of your use or you might need to do some use changes uh depending on how you use them and so we will talk about the different

ways that you could use them and how it impacts um your setup um especially for the merge right so let's get started and let's start by um talking about bum the new features or the new changes that are coming with the merch what are the main ones that stakers should be aware especially in relations with these providers right there's really only two big changes that are coming one is that the connection between what we thought of as the the beacon um client and the eth1 client right so like your your lighthouse and your guess which we're now calling the consensus

layer client and execution layout line this connection changes it's currently using uh the standard query rpc api and there you see it that's the json rpc api there and that works perfectly well to any rpc provider like a um inferior or something like it and all it does really it asks it hey have you seen any deposits to the deposit contract that's all it does it's really lightweight after the merge this changes to an engine api and this execution client here right that you see here this no longer knows what the correct chain is that's the whole point of the merge it has no idea anymore it needs a

beacon node client to tell it where to go which means that by the nature of these things because it doesn't have its own consensus anymore profile work is done proof of stake in the beacon node client is the only thing now that knows what the correct chain is you can't have like say 100 beacon node clients all talking to one execution client doesn't work you know you can't have 100 people it's giving you different direction as to where to go next so therefore this needs to be a one to one relationship which means just for technical reasons public providers cannot offer the engine api yeah and i mean there's a few subtle um details there but essentially

like a consensus clients will have to drive one execution client correct and so the relation here is that the consensus decides what's the head of the chain and it tells the execution clients to to update to this head point right yep exactly that's exactly where it is that's the whole point of the merge right that's what we're trying to do get away from two chains have just one um this is no different you know some people ask but can i do this can i do that this is really no different from how it is now i want to stress that right now pre-merge idio execution client there is consensus code proof of work or proof of authority

and it's a one-to-one relationship every execution client comes with its own little bit of code that tells it what's the only difference now is we've made this more visible there's a beacon node client that talks to it and does this job so it's it's way more visible that there's consensus code but it hasn't changed this one-to-one relationship is here now and will be there then and so like people keep asking us like is there ways to do some like failovers or like is there ways to have um a consensus client drive many execution clients or like the reverse have any execution client

being used for many consensus clients and there might be some ways to do that and we might not want to get into too much detail so these ones yeah we'll get a little bit into the weeds if we if we go there but like like in theory you could have like um a one-to-many relationship between consensus and execution client right you could have like yes um yeah that would work right you could have one consistently a client telling multiple execution client what's next you will need something in between called a multiplexer there's not a whole lot of code yet that does that and it's not been tested

terribly well as you might expect right but yes that's entirely possible and then also you see down here this validator client talking to a beacon node client the validator client you only want one of those because it's got your keys and if you have multiple you get slashed but nothing says the validator client can't talk to multiple beacon node clients it absolutely can yeah right so you can have a validator client pointed to two beacon node clients each beacon node client has its own execution client behind it and there's your failover that's another way to set up um um in theory there could be another way too where like you have a single

execution client being driven by multiple consensus client but only one of those consensus client will have to tell what's the correct head position or like what's the yeah i know there's a proof of concept that has that idea that peter from the guest team wrote but i don't know that anybody's actually tested that so for now let's just say no so so yeah so in theory there's a bunch of these things that could be done but like in general that's gonna be like the typical customer you know if if if this was way too much and you're just gonna keep it simple you have a execution client that handles all the transactions and you need one consensus client for it and that's it

one-to-one relationship that's your ethereum four node so what's the other major change that will impact stakers and potentially providers um with the merge the other major changes that the validator client that you see here talks to the beacon node client and says give me my loots to this address that's a fee recipient address and that's where the priority fees go so the fees that the users pay not not the issuance from the chain but the fees that users change pay in transactions and then mev maximal extractable value that will also be paid to the fee

recipient and that's immediately liquid right away can be spent anytime yeah and so if you're using any kind of public infrastructure provider in between all of these relationship or these connections um you might have some issues and we'll come to those um eventually as we we go through um how the engine api is being used and how the fee recipient address is being used but ultimately who decides which fee recipient address is being used um for a new block well that's the interesting part so the

the protocol between the valid client and the beacon node client is by design not authenticated which means there is a message that says go use this fee recipient and then there's a separate message in which the validated client goes and says i've signed this block so it's entirely possible for someone to hammer a reachable public beacon node client and tell it my fee recipient over and over again hoping to break through yeah and so but like in the end i believe it's the execution client right it's no it's the validator client it is the validator client that tells it where the feed recipient goes um so typically the beacon node client

has a fee recipient built in that it will use if the validated client doesn't say otherwise and then the validator client can say for this particular public key i want you to use this fee recipient yeah but i was under the impression that eventually the beacon no client will tell the execution client to use this the beacon no client will use this when building blocks yes that's correct i will tell it that so we're more concerned about though you know with this connection between violet client and beacon node flat yeah all right so maybe we should go through like what are the current scenarios in which people are using uh infuria or any of these other public

infrastructure services um service uh with their staking setup right so let's start with the the first one the first one being like using infuria or any of these other services as a way to to make this conversation um much simpler we'll just keep calling them inferior because um it's gonna be easier for us but like let's say let's totally not shilling them yeah let's say um you have your own staking machine and you're using infuria um for your full execution endpoint um and this is actually a pretty common setup um when we did a an informal reddit poll we were

told that about 20 20 of the people who responded said they're running this way that doesn't mean that's the actual number because i mean reddit is self-selecting right but yes there is a non-trivial amount of people who run this way for a good reason uh the execution client takes a lot of space on disk current recommendation is two terabyte of space available and it takes just under a terabyte itself right and it generates a lot of traffic which can be an issue for people with data caps so it's entirely reasonable at this point pre-merged to say i'm not doing that all i'm doing is i'm asking it when

have you seen a deposit that's so lightweight i don't care to run the full thing so if you're in in this situation um you might need to take immediate actions here because after the merge you'll need your own execution client as we mentioned before um a consensus client um like an execution client has to have like this one-to-one relationship we should maybe this is something we haven't mentioned here we should maybe say what's the impact of stickers right so pre-merge right now what happens if this json rpc api is cut right and you don't have the execution client well the answer is not much happens your beacon no client will continue a testing just fine

it will even continue proposing blocks as long as those blocks don't have deposits in them so impact is really minor right now the impact is absolutely minor right like potus um i'm gonna just name check him here uh famously was of the opinion that it would be you know narrowly rational to just not run one at all and not even have a connection to anywhere just don't worry about it it's not worth the hassle right and he said that like in a year he hasn't seen a single proposal with deposits in it on his personal validator they are all over the place in the network of course doesn't mean you will see one right so pre-merge

no big deal post merge completely different story now you need this thing for every single attestation plus of course the proposals and so post merge um this setup's not going to work right because correct the engine api is not going to be offered by infuria and they can't right they'd have to give you a full execution client full fat just for you and that that's that's not their business model their business model is to have a whole farm of these and then load balance and have a whole bunch of people hammering them right that's that makes sense you want to you want to have some some economy of scale here so

they technically cannot offer an engine api because it would have to be a one-to-one relationship absolutely so what should people in this situation do to prepare for the merge they should take this execution client square here and just mouse click drag it over to staking machine like that yes so that should be your main solutions like there's other solution but this should be your focal point here because like we said that's it you'll need an execution client paired with your beacon node or your consensus client right just run your own just run your own you know there's a few considerations like uh

york mansion like disk space is one band bandwidth usage is another one because the execution client is gonna have to talk to this execution peer network and and we can help you with that if you have any issues just get in touch with us but um that's the main solution that you should be focusing on and you can prepare for that you can start running your own um execution client you can even upgrade your hardware if you need to um there's a bunch of people who are currently like buying um a slightly bigger disc like this two terabyte um ssd that we've been mentioning before should probably be the general recommendation if you're running this on

yeah that's a that's a good solid recommendation there's a way to get by with a terabyte but it gets a little tricky so two is a is a great recommendation so let's go to the next scenario uh that people have been using here so this one here is is not much different than your typical um setup but this one uses um infuria the um execution layer as a fallback um and this is a scenario that is also popular with many different people quite popular yeah so maybe we need to talk about you know first what's going to happen well you won't have this fallback yeah but then let's talk about well why did you have the fallback in the first place and what else might you

be able to do so typically people have this fallback because they need to do maintenance on the execution client if they're running gith which a lot of people are the thing needs to be pruned offline pruned every so often right that takes about and a fast machine maybe five hours um during that time you'd post merge you'd be down because you can't attest at all and if you get you know a proposal during that time you're really sad so there are options one option is to say i'm going to choose a client that doesn't need to offline prune there is work uh being done by the guest team to have

that be geth so that's an option gets into you know you really don't want to be on a super majority client we can have a separate discussion about risks of that and why you might want a minority client so that's one option you wait for that second option you choose something like an aragon which grows by just the gigabytes per week so if you have a two terabyte disk it will last the space will last longer than the hardware will and then the third option is a client that does online pruning so never mind comes to mind never mind for example can be online pruned takes a lot of resources

as far as you know cpu and ram goes but absolutely works and will online prune itself while it's running i believe there's a for a fourth option to maybe you just accept the downtime when you need to do maintenance too sure so also absolutely possible and that is also a question of you know um how many validators are you running here you know what's the risk that you're getting a proposal during that time because when you get a proposal you get more rewards and you get more rewards you get mev you get all that stuff you really don't want to lose out on that particularly post merch you don't want

to lose out on that because a lot of your api is going to come from that right when we hear post merge apys higher that's a hundred percent on block proposals not on attestations that's that's correct right so just to pass the message again here there won't be any engine api offered by infuria so that scenario is not going to work for you when you need to do maintenance or when your execution client has to go down absolutely for this all right so let's go to the next one um the next one is um someone who has a sticking machine with just a validator client

using a full consensus endpoint on inferior i don't know if anyone is using this um setup here i've heard of people doing that um the effectiveness isn't great like the effectiveness as as measured by beacon chain i recently actually switched somebody was doing this over to running their own um effectiveness went from like 75 to 98 right so but if you're doing this um this is tricky to say the least after merge uh first we don't actually know whether inferior will still offer this on the call today it sounded like they would but of course there's still time

until merged they may change their mind right fee recipient address exactly question marks we should have a link here to adrian sutton's blog post about this yeah we'll include that into the description yeah exactly so this comes back to this problem that the speaking node api here this rest api is being used is not authenticated anybody can send a fee recipient address for your public key and of course you will and then they will right so they can just hammer the speaking note client over here in fuhrer and hope that their message comes through in such a way that it gets honored rather than yours

and then you don't have your fees that's a real real real risk here um of course they don't know which beacon node client they're hitting within fiora right but because this is all load balanced on the back end there might be 30 of those in there no problem they'll just keep spamming infuria with send it to me messages hoping that one of those lands on the big note client that you're on and if it doesn't even just a couple do you know that's that's money in the bank so it's it's a real worry um at a minimum i would ask infuria about this i would say how are you handling free recipient address and the risk of these fees getting stolen if i point my vow to the client to your

there might be also like legal or support um concerns or issues with all of this right well i mean i i can't talk to infurious business model but i would say if this was me i would not in a million years want to be in a situation where a customer comes to me and says um you caused my fees to be stolen that doesn't sound like a good time yeah it doesn't sound like something you'd want to do but like we we don't know exactly their what their plan is we're not informed um we haven't been they will actually have a work um [Music] a workshop right a workshop yeah they'll have a workshop next week specifically for stakers

so uh today is the what is today's date we are july uh 12. it's where 12 okay so i think july 19th um they'll have a workshop so if you see this after it's old news but if you see it before then uh go go poke them a little ask them how this will be handled because it matters all right um let's keep going with the next scenario here this is going to be with um someone using infiera as a checkpoint sync um source for their data so this scenario right so it's just gonna keep this will

work this will keep working we should maybe say what is a checkpoint sync because not everybody knows so the speaking node client here if you're syncing it from genesis which is now a year and a half plus ish away from us it can take days literally days to synchronize or you can get a checkpoint from a trusted source such as infurer the beacon node will start from the checkpoint and then it will backfill it will still validate the entire chain but it'll do it while it's already running it literally takes seconds to synchronize a beacon node this way and then it still takes days to backfill but you don't care about that it just does that right so it's ready it's uh

mainly it's ready to to do its thing and validate on your behalf or rather you know send that to its other consensus peers right away so that's a good option to have and that option remains nothing changes here with merge that's still absolutely doable that ends the different scenarios that people are using these um public infrastructure um services let's quickly talk about inferior's business model here um like we we don't we don't know exactly what inferior is doing like what their plan

what their plans are or like what they they want to do with all of this but um we can read their website we can see what they're proposing um as their offer and and it seems like infuriate is not in the business of providing staking services if if i'm correct at least not so far yes and fura is a is a rpc provider a query provider right they they're mostly used by dab developers by metamask as you mentioned etc anybody who needs to query the chain and needs to send transactions to the chain that's their bread and butter that's what they do they do it really well and they will continue doing

it that does none of that changes with merge that all stays exactly the same way it is now exactly and and even if they have this huge underlying infrastructure it doesn't mean that um they they want to provide staking services as part of their business model or that it is easy for them to provide uh such services from a legal standpoint or even like from a support standpoint uh they might want to avoid providing those services well right now it's fairly easy for them right because there's no there's little risk if you point around in a client at the at their consensus layer client the worst that happens is that the performance isn't great

but i mean you know they can just say well it's a free service what do you want right post merch this worry of fees getting stolen puts this in a whole a different ballpark and so like maybe they just don't want to deal with that um that could be it could be that they just say we're gonna you know they do have uh filters in place so not all um methods can be used that's a standard offering and so they could just say we are allowing consensus layer rest api queries but we're not allowing violator client

connections because too much hassle yeah you know we don't know we'll see what they have to say and so what would be the um different alternatives uh for people who are currently relying maybe a little too much on infuria or any of these other public infrastructure providers yeah so that that gets interesting basically you'd have to um find a way to uh run your valta client yourself right or give your keys to a non-custodial provider so to run it yourself you can do it at

home but for some people that's just not an option because of internet caps and the like you can stick this into a vps you can get a vps for i think under 50 bucks a month that has sufficient performance to run this not as cheap as running at home maybe but you know if you needed a an internet upgrade then it might actually be the same cost so those are really good options there with homestaking of course being the gold standard if you can't do that you might put it into you know an affordable vps and if that's not an option then i think as far as i know i'm a

little reluctant because i'm gonna name a name but as far as i know the only truly non-custodial um service that's still around is block staking so they actually take your key or actually they don't take your key you take your key use their um program and it creates a what's called a remote signer think of this like but that's the that's almost like a validated client just even smaller all it has is the key and its science duties and they create this remote signer in your amazon account and that's where your key stays and that's where it runs so it's completely under your control and then they run the entire rest of the

infrastructure the volatile client the consensus layer client the execution layer client but they don't have the key ever the signing every other provider that i'm aware of needs your signing key because they kind of do right without a signing key how do you sign duties blocks back in the day had this idea that if we run it in your amazon account then people will flock to us turns out the kind of person who wants that service um is a little freaked out by needing to know how to give someone access to their amazon account to run a remote signer we're way too technical already so there's a few options like there's

still a few options yeah those are the ones you have like limited resources or technical abilities um there's a few options available to you yeah and then 2020 when we're talking merge well that's that's this year right 2023 sometime we might see hopefully this year right we might see 2023 uh we might see some options um called dvt distributed validator technology from maybe one or two providers and that would allow you to split the key into pieces and then you know node operators run the pieces and come to consensus threshold signing and then so on so that's that's kind of clever

um it was in vitalik's roadmap i believe but it's not here we don't have it for mainnet all right i believe that's um all we had to say about this so if you're relying on these providers and and you need help about like what's your next step to prepare for the merge make sure to to get in touch with us we have some great support on reddit and on discord we can help you with all of these options we can guide you through setting up your own machine trying to install your own execution client if you need to um we'll gladly help you help you with all of this that'll be you personally right um probably me or you or like someone someone we we wiggly talk on discord

these days right exactly all right so that's pretty much uh that's pretty much it thanks for watching and we'll talk to you guys later