Jason Vranek - Native Liquid Restaking

Transcript

🔍 Native liquid restaking protocol Puffer offers increased capital efficiency for validators, but concerns about proof of state congestion and centralization should be considered, with a focus on future problems and the journey starting with an out-of-protocol solution called secure server.

all right well welcome we'll go ahead and uh start with the next uh speaker here it's a little bit ahead of schedule but that will give us a little bit more time for the presenter and for questions afterwards here so very pleased to um introduce you to vason Jason vanre who is the uh CTO and co-founder of puffery and you're going to be talking about Native liquid reaking awesome yeah thank you so much for having me here um yeah so I'm going to talk a little bit about puffer um some of uh what what was our our journey to get here so um we'll kick it right off so puffer is a native liquid reaking protocol there's a sort of a lot of new words in there so I'm going to give some

background first um and yeah let's get get started so I'm sure all of you are probably familiar with liquid staking tokens but um for the rest of the audience maybe watching um I'll try and give a quick background to to really see how this contrasts uh with what we're doing at puffer so for recap um pretty simple stakers Deposit eth they mint some kind of liquid staking token and nodes are able to borrow these this eth to run validators to generate proof of stake rewards um they earn a portion of the rewards and the rest goes back to the liquid staking token holders and the idea is that these stakers can redeem eth um plus rewards minus any penalties accured by these validators um at the

future so um there's there's some um pros and cons here um I think the industry is really leaning towards Pros um because of the yield of um lsts the the ease of use the liquidity the ability to like take it to defy um but also from the node operator point of view there's this increased Capital efficiency like you don't need 32 eth um to run a validator but of course there's the cons um as we saw from Mike's talk at the beginning we have proof of State congestion um we have centralization vectors where um proof of stake as the validator said is kind of starting to get dominated by some protocols and really reduced Economic Security when

we're talking about um permission liquid saking protocols where the actual node operators aren't putting down collateral so while the industry today might be leaning towards um the pros I think really we should be focusing on tomorrow's problems um because they might be sort of worse than the benefits we're getting today and so this was really um how like our journey started um but we're also coming from like an outof protocol solution so you might know puffer a little bit from our first sort of intro um we built this thing called secure serer um it's this anti slashing um kind of mechanism and actually ltis L will be giving a talk on this in more depth um later today um so I'll just kind of cover it at a very

🔒 Liquid staking protocol implements secure enclaves for validator keys, adds anti-slash rules for security, decentralization, and participation, aiming to be permissionless, safe, and profitable.

very high level but the idea is that you have um what's called a secure Enclave um in the current implementation we're using Intel sgx as a trusted execution environment and the idea is we're going to expand this to other Hardware manufacturers and what you do is you really generate your validator key and um store it within this um this secure enclave and as the actual validator I have no idea what my actual validator private key is and this is important because it really prevents me from shooting myself in the foot I'm not going to accidentally be running a validator um on like two separate clients and um get slashed because I I don't have the ability to really take my

key and put it in multiple places and these um enclaves are pretty interesting because you're able to actually um add logic within them and what we're doing is we're adding these anti-s slashing rules very similar to what your um normal like validator clients and consensus clients are already doing but it's just um considered a strict security enhancement Because the actual like logic is within this tamperproof environment um and so we we built this as part of an EF Grant and open sourced it so um while we use it within our protocol and it's also available for solo stakers as well and I think that's like part of lisl's talk is on how solo stakers can really be using this so this was like our approach and when we came

um into um building puffer and the idea was okay we can reduce slashing risk and for a um permissionless um liquid staking protocol this really means we can reduce the bond requirement um which would help more validators really be able to participate and that helps increase decentralization and the end like did we solve this or is this too simple and so puffer has really come a long way since that um definitely this this enclave and um secure CER is a a big part of our protocol but we've we've kind of um come a long way since then so where are we today so we in building this protocol

really wanted to follow some guiding principles here so the main one is um we have to be permissionless um from day one and always and um the protocol should be safe and this always of course for stakers um like the people holding the LST but also um for The dode Operators so this is where um technology like secure CER comes in um eventually that can be um complemented with DVT as well um and then it should be Capital efficient it should be um accessible for node operators to be able to participate um and it should be profitable for those node operators for people to actually have the incentive to go and run um and of course scalability if your protocol isn't scalable then

you're not going to be able to attract enough Capital to grow and really on board more validators as well and finally um ethos alignment U maybe most important here is that the pool should really be self- capped and try its best to follow along with the ethos of the community so okay with that being said um following those guiding principles really what is puffer at a high level so we're ethereum liquid staking where you earn proof of stake rewards with your validators but we're also doing native reaking on top of igen layer so that's able to generate um reaking rewards and maybe a quick clarification here because I think this is often lost is there's a difference between native reaking and

🔥 Puffer introduces native liquid restaking on Ethereum, with a new feature "smoothing equipments" and upfront payment for validator rewards to address low collateral incentivizing theft of MEV.

kind of regular reaking whereas n or regular reaking is like you take your liquid staking token um and you restake that to run some of these igen layer abss with Native reaking you're taking your um ethereum validator layer Beacon chain e and then reaking that to run different applications so what is this result in so puffer we're calling this native liquid reaking and instead of a liquid staking token we're calling this a native liquid reaking token so so um that's kind of the overview so what are what are some of the features so one thing we put out um last week was a post that we collabed with Justin draon

called smoothing equipments um and the idea is kind of um very simple but also kind of interesting um and I think it opens a lot of um potential research as an outof protocol kind of um Technique we can use so the idea is that if I want to run a validator for a certain number of um months I can actually pay upfront some um close to the expected value of what I would make as a validator and in exchange I get to actually keep all of the rewards that I generated so all of the consensus rewards all of the Mev and this um really has um a lot of interesting um kind of results so one of them is from the point of view of

stakers um like on puffer they actually earn months of rewards upfront rather than over the course of many months and so this has some nice growth um properties for like an upcoming liquid staking protocol to try and compete with these more centralized ones and another important thing is um I think Justin pointed the phrase rug pooling the idea where if your um validator um collateral is really low then there's actually a clear incentive for you to try and steal Mev if you get this juicy block that's worth more than your collateral and actually trying to police that and course that is like probably an unsolvable problem unless we have some kind of enshrined solution like Mev

smoothing or Mev burn um and so yeah feel free to check out um at the bottom there's a link to the the research post and so what does this look like now to to become a node and puffer so there's um kind of two two flavors here if you're using secure CER and you're able to prove it and we built these smart contracts that allow you to be able to prove that you're running um the specific Enclave then your bond is um lower and so you'd be paying um locking one e collateral and then paying this smoothing commitment for whichever duration you prefer um but if you don't want to actually use the hardware or like um like get if you're having difficulty getting access to it or you

🔒 Stake your bond in puffer protocol, use non-reking modules, borrow ETH for validator; strategy operator runs multiple strategies, ensures immutability, distributes rewards to validators and LST holders.

want to run it on your existing setup then it would be a slightly higher Bond so okay how does this all come together like um in puffer's actual architecture so we have these things which are calling strategies um you can also think of them like reaking modules so the idea is that a node would deposit their bond um into the puffer protocol and sort of the main thing here is that we have this non reaking kind of module as like the most big one like we we don't want to like we want to like diversify in how all of the eth is distributed within the protocol and prioritizing the non-ring um is sort of the least risky um so then what happens is so the node after

they deposit they're going to borrow um eth to run their validator and they're going to deploy that into the strategy of their choice so for example that could be a strategy that runs igen da it could be one that um runs like the mock alt layer stuff that we just um saw from the last presentation um or any new abss that come to Market and combinations of them but one important thing is that um the actual strategy should be immutable in the actual avss that it commits to so that it's not just adding new ones that could cause um slashing and so how is this broken down so each of these strategies will have many different validators deployed into them um but

they'll be run by one strategy operator so what this looks like is the strategy operator is the person that's actually running the abss um but then part of the rewards are trickling back down to these validators that are within the strategy and also down to the LST holders as well so what this really um looks like from the point of view of a node operator is I can deploy a validator for um like much less Capital into one of these strategies and now I'm able to also earn um reaking rewards on top of um my proof of stake rewards and so increase um the viability and the profitability of my validator so what is um so puff eth is our um native liquid reaking token or

🔑 Node operators can increase profitability by earning restaking rewards on top of proof of stake rewards and deploying a validator with less capital using native liquid restaking with Puff Eth, leading to rapid growth in conversion rate.

liquid staking token and it it is a combination of these reaking rewards these smoothing commitments paid by the validators and also the stake e deposited by the stakers so maybe let's try and recap real quick so stakers are going to deposit eth and these nodes are going to pay smoothing commitments and deposit bonds um they're going to then give a month's worth of proof of stake rewards upfront to these um stakers through the the smoothing commitments and the node is then able to borrow 32 eth to deploy it to the strategy of their choice and um this eth will be natively restak and then run um by one of these strategy operators and this will in turn generate

reaking rewards that sort of flow back through the protocol and pay back the validators and stakers so um there's some interesting Dynamics when we're talking about these smoothing commments and these like High up front payments from the node operators so we're calling these things um growth spurts so one way to think about it is that whenever a node joins puffer now the actual um yield on the native liquid reaking token will increase so from day one this might start as like um just one to one you have one eth is worth one puff eth but then because of this high growth Dynamic like very quickly you can see how like the conversion rate um can

really um grow and I think this this is very um kind of interesting um Mike had also talked about um the churn limit and that's being um introduced in one of the future eips and um from the point of view of puffer like we're trying to compete with some of these centralized liquid saking protocols but the turn limit also sort of slows our growth as well but it's interesting because through this Dynamic we're actually able to get some bootstrapping and growth of our protocol um before the validators even hit the the validator set so um that's where growth sprs come in but um of course in ethos alignment um we have what's called our burst threshold so once we hit that 22% threshold um the

🔑 The Native Liquid Restaking system addresses safety, diversification, bonding, rewards, and protocol cap, with a focus on low latency and implementation for Node operators.

protocol will automatically hike up the fees and sort of um economically like reduce um the incentives for you to join as a puffer node um yeah so let's maybe wrap this up and highlight some things about puffer so we tried to sort of go back and um see if we we reach some of these um guiding principles and so for safety we're having our anti- slasher we built it with sgx but we're starting to diversify that into multiple different Hardware manufacturers and of course like all of our nodes are bonded um to prevent um or to sort of align things better and also because we're permissionless um and then for the viability of these node operators and

the growth of the protocol we're combining these um proof of stake rewards and the reaking rewards as well um and of course yeah for ethos alignment we're capping the protocol to 22% so um with that yeah thank you so much um and I'm yeah happy to take any questions and um yeah please these are some of our links we're we're going to actually be launching on the public test net this month um so yeah please join um run some puer notes but thank you we have time for um multiple questions does anybody have any questions for Jason hey Jason great talk so I have a

quick question when you run the like sort of the sjx is there any um like sort of major latency compared to the nose with sjck just want to know some of the data yeah actually yeah very very low overhead um and also in the implementation if you're familiar with web 3 signer um built from consensus secure signer is actually just um like a reimplementation of that in R so in R like nice and fast and yeah there's um little latency see sounds good another question can you um like um go back to the slides with the the the loop um yeah yeah this one so um I I just

want I'm curious about like um so uh which component um like in the future you would like to apply the SJ in like uh will it be um on the not side and also the operators and uh um so what are the like components you will have with IX yeah yeah um great question so primarily right now that's starting on the Node operator side so when you're actually registering your node you're actually going through this process of remote adastation where you're proving that you're running this specific Enclave that's running this specific set of software um and really what this is showing is like you generated the key inside of the enclave and The Enclave is

🔒 Registering your node involves proving specific software inside an enclave, with the risk of storing keys on a physical machine.

running all the necessary SL um protection logic and yeah you're able to prove on chain that you're running that and get accepted into the protocol so that's where it's used today um and we're going to yeah expand that to other Hardware manufacturers but actually moving forward um I think there's a lot of interesting applications of that especially um in the context of igen layer so like we're doing this for ethereum proof mistake to prevent equivocation from our nodes and equivocation is one of the things in like many many many of these abss and so you can actually reapply that same technology and have like so from our strategy operator's point of view like if they're running another consensus protocol through igen layer they would

be able to use sgx as well and prove that they're running that as well any other questions from the audience here um I I had one for you Jason um maybe two um the first one is with regards to storing the signing key the validator key and The sgx Enclave in there what what are the risks not being very familiar about that system but is there a risk of maybe that node getting damaged or destroyed and then losing the key is there a way to back it up on steel or in some other secure system yeah so that that is definitely one of the trade-offs is that like if you're Hardware is just like obliterated um you

the idea is that it's only on that physical machine so you won't be able to recover it in that case so we really recommend pre-signing these exit messages in advance um so you'd have to withdraw in that case but also um post EIP 70002 you'd also be able to do that through the smart contract yeah that's a that was one one of the thoughts I had and then a second follow-up question is with regards to the comments you had on the Mev theft the stealing of the Mev what what is the approach or solution that you're taking now to um ensure that your nodes that are bonded with the one eth or two e are indeed um sending that Mev to the correct um uh to the correct fee recipient yeah yeah so so that is kind of the hard U problem is like how

🔒 Pre-sign exit messages and withdraw through smart contract to prevent MEV theft, using offchain solutions and MEV Bur to ensure nodes send MEV to correct fee recipient.

do you um how do you enforce that so you can like use these offchain Solutions like using an oracle to check like okay if our validator U produced a block and the fee recipient is incorrect then we can go and like slash their bond but really this is like a difficult problem because one now we're introducing this extra dependency on like an oracle um maybe uh once uh 4788 comes out we can do that more trustless but I think the major issue here is that we don't know if there's like offchain deals going on where like maybe just pennies of the Mev is actually sent to the few recipient and the rest is um done off chain so this is where like um real like in protocol things like Mev Bur would help

that but the idea with the smoothing commitments is from the point of view of our protocol like we don't care anymore if you're keeping all of the myth because the idea is that you paid up front close to the expected value of it um so that now like Fe recipient goes to your own wallet and that's fine okay excellent excellent so that's that's part of the uh the Mev commitment smoothing is is actually an upfront cost and then the node operator gets to keep the MTH yeah exactly okay excellent any any other questions from the group before we let Jason go all right well thank you very much thank you