Nektar Network | Dr.Miguel Prada - The restaking endgame is powered by DVT | ETHDam 2024

[Music] welcome everybody to day two hope you slept well got some good rest I'd like to welcome Miguel from nectar is going to be talking about DVT thank you very much um and thank you all for coming here yeah we wanted to talk about uh nectar uh RIS taking and how uh DBT play a role in this uh new emerging topic so my name is Miguel as you probably guessed and I'm going to talk about uh um how we are working to introduce in DVD in Risk taking so first of all we want to uh ask about you know how many of you know about the the situation of uh staking right now in ethereum we have a situation where Lio uh is controlling most of the stake and you know that is mainly centralized in in a few players going base binance so mainly centralized exchanges um so staking centralization everybody agrees that it's an issue because you have a few parties running all the validators um and then go any slashing they could have a failure they could uh have down on the servers and cause major damage to the stickers that are depositing the trust into them um but uh nobody's talking about risk taking like everybody's okay with a few operators running all the risk taking so if having an entity with 33% 30% 20% is an issue imagine having one where all the are not trying to pile up into a single entity that is also running all the validators Via centralized operator so just having a few operators running all the validators all security whatsoever just I mean there is security but it's all centralized into single machines running the validators there so if something happens no collateral nothing just everything run by uh F few operator so something that we want to to start explaining maybe is what is raking anyway because it's something that many people ask like do we really understand what risk taking is because it's a word that doesn't really tell a lot about what you're doing so the way we like to see it is that raking is just first of all you are repurposing your Uther you are depositing some collateral into the network and then you're providing it as a guarantee that you're going to behave honestly uh so yeah instead of just acting honestly on ethereum validation which is a single thing you want to report proc it to say okay if I misbehave on ethereum validation or in other of stuff like one of these list then I can be penalize with this pot that I'm putting up from um so the thing is that if you are a last in ethereum you should also be slashed in this other networ so if you were running a validator and suddenly you are slash you should be also SL last and kicked out from all these other networks that you are running and vice versa if you are running something on these networks you should be also kicked out out of the theum validation but you can already see where the challenges and the problems here are so if you're running something like a bridge which is another service that you are uh using the collateral of the vator to uh support and you commit an offense you did something wrong you're penalized on the bridge Bo and the problem is how am I going to slash you on the validator because anyway you have the keys so how am I going to exit you how am I going to penalize you how am I going to take your res from you because they are on the Bon chain so there's no way to really R those e and that's a problem with running the operations of value to a centralized point that if that centralized point doesn't want to cooperate on being as last which probably doesn't want to then there is no way to really uh uh take the ether from them so um risk taking in general um Leverage ethereum security so what it does is uh uh it help you in a few things so it has in theory you could think okay using ether to collateralize many things can have different issues because it's like re hypothecating something which can have like bad effects if not read it correctly and that's true so um it has certain benefits one of them is okay you a new project you don't have an Network you don't have any trust from anyone but you want to Boost dropa network um so how do you gain users and how do you gain uh knowde operators that are that you can rely on so a good way is using restake because you know that these operators already have a a big pot of collateral they can be thrusted because if not they're going to be penalized with a big amount and it's not just some shady token that you're just popping and maybe you know it doesn't have any value is a real um yeah they are real ethers and if real I mean for real ether to go to zero the whole platform the whole the will need to go to zero so you know that you are having a really secure uh uh asset collateralizing the the protocol and also they can benefit from the users and the traction that the whole ecosystem is providing so at the same time you're able to boost strap both users and no operators for the network that you are creating on top of the raking uh protocol so and there is a third thing which is that by having all these combinations of networks plus the reaking of The Ether you have an aggregated Revenue so instead of having only a source of income from the ethers of the validator you now can have an income from a bridge from a rollup from you know different incomes that all go to the same pile increasing the revenue of the RIS takers that are putting the collateral behind the services that are being run by The Operators so it adds a lot of value even though of course uh it has a some other challenges so as you may see on on this sentence from vitalic um it is that well rep purposing the ethers that you are using as collateral is good but is not uh good is to recruit on to to use the Ean consensus to um for for your application but as long as you are only using the capital penalized and that can be done just as simply as an smart contract that it's going to take the E from you if you are misbehaving or is able to expel you from The Valor if you're misbehaving and you're you're good to go so um there are some other areas where things start to get a bit more shaky so we talk always about risk taking in terms of collateralizing with ether and that's perfectly fine because if for ether to go down as I said you need the whole network of e to go down which is where you are building so anyway if that goes down then who cares so the problem is when you collateral with something else so imagine you had has collateral USD from Terra right right or FTX tokens then in that case you end up with certain Services certain validators that are being run by something whose value is zero so then what is the incentive for those operators to just keep running them or just not I mean why why not slashing because there's not going to be any cost it's zero anyway so this is where things are a bit more problematic um and you can end up under caliz uh out of the sudden so what can we do with DVT here like what why DVT is important why why why this can help a lot into risk taking ecosystem well in general RIS DVT offer certain uh properties um uh blockchains tend to have the properties of always continue you should never stop a blockchain you should always be able to progress come to consensus produce a new block and continue creating blocks and and transactions um on on a validator you don't want exactly that the validators want something different and the validator needs to and if you see in ethereum they they want to validate they want to always be secure never be a SL but if you miss an attestation etherum is designed to be okay like you're going to lose a small amount of Revenue due to this atation missing but that's okay like it's not a big deal but the priority is never gets lost that's like the number one if there is some liveness issues that's okay but never gets lost so DB protols need to focus on on that and this of course um I have have certain benefits on raken which we will see now um so in order to for a DVD protocol to work there are like two major phases one is that um you take a validator and instead of being run by a single operator that now is going to run the services and the and and the raking and everything you take those validators those keys that before you could not uh have them uh The Operators have them uh so you could not exit them you can not uh with withdraw them from from the valuation and now you split it into multiple operators so now it's not run by a single entity but it's run by many operators so this group of operators behave as a virtual validator they are all working together to join cryptographically and uh sign as if they were a single operator um so each noes need to First agree on the data that needs to be signed for that to work and secondly it needs to uh they need to each one sign and then aggregate the signatures um so um you can have different parameters of M and M but the general idea is that you have to have like more than half of the uh notes participant threshold meaning that if you have let's say 10 nodes you should have at least a threshold between five and 10 meaning that you should have five out of 10 for the threshold six out of 10 7 out of 10 8 out of 10 does it matter which one is the value it has certain pros and cons going to one side or the other if you go more towards the higher end so closer to 10 out of 10 uh you have higher security but you have lower resiliency meaning if you have a 10 out of 10 if one single Noe fails is have if the whole body there will fa because you need a 10 out of 10 to to aggregate the signature if you have a five out of 10 you have higher uh resiliency but you have lower security because with fewer ND you can uh get control over the validator so um with with the DVT we can have different benefits and the benefits that we can have with these properties of splitting the keys is that what first the collateral you deposit in the validator is now not deposit by a single operator but it's deposit by a group of operators so if you have 10 operators then if you had to deposit 8 16 10 whatever amount you now split that number between the number of operators therefore each one of them has a lower value to entry to becoming an operator and a raken protocol uh secondly I mean it enhance the centralization you don't have now a guy that can unilaterally slash and cause damage um and the same thing is yes it it doesn't control nobody controls like the full validator meaning that if someone is misbehaving as an operator on reaking part of the as part of an AVS you can set the rest of the peers of that node to expel them from the validator so you now you don't need to trust them to be slash and cooperate with you on his pass in them because now the rest of the peers will be incentiv and aligned to expel them from the validator and now you can penalize them because you can expel them and you can penalize them on the ABS and you can penalize them on ethereum because now you control the keys because the majority controls the key not a single operator that's where the DVT helps a lot into into hassing the the protocol even right now before we have the 7,000 to EAP of the uh exiting via VIA calling execution that would be be a great H as well but this is already a great measure that can do that can provide a solution today and uh and more on the cryptographic side and on the smart contract side the only drawback of this is that well it's it's generally complex on abss to generalize the penalization because when you have many services you have a bridge you have a L2 you have a rollup or whatever all of those have different properties with different proofs so issuing a proof of what is misbehaving in a generalized way that can be penalized on a on a contract is a really complex problem so that's what we are working on into into uh breaking down this problem into pieces and being able to individually penalize each one of the operators that are participating both on the DBT validation and uh on the ABS uh running and I think that's all from my side I prefer to uh answer any further questions if you guys have uh any um but yeah I mean thank you very much for for coming and for uh [Applause] does anyone have any questions yes yeah thank you um I just have a question uh does this approach have some drawbacks I mean maybe in latency or I don't know yeah I I had some slides PR about latency but I didn't have in in the end time to to add them but yeah it's a very good question so generally there is like uh um the liveness and the security but then latency tends to be get affected especially if you need to come to consensus on the data before signing the data so that's where um there are like two approaches like if you think on the um uh blocking point of view you need to agree on the data before signing it and then they all sign it and why would you do that well I mean you you want to sign the same data so you can aggregate it right right okay but the problem is that you can do if you introduce a consensus before signing consensus can be slow and they can disagree and you can have multiple iterations which adds this latency and and delays right so adding a consensus before signing so then you can produce the signature and add it to a consensus Pro which is ethereum is going to introduce a lot of latency which in ethereum it translates to higher inclusion distance and you're going to have lower uh income so another way to do it is um our approach is to not do the consensus on the data but do the consensus on who needs to propose the data and then there are different things that you can do which is okay but what happen if the node signs well the nodes are not going to sign blindly they are going to check the data so already the thres signature provide you the consensus so you either don't have a signature or if you do have a signature the threshold is providing you the consensus on the aggregation over the data that you're signing so you don't need to do a consensus before that second consensus because the by the by itself is already a consensus on the data if not they will not have signed it so that's how you we are able to crack down a more on the on the speed up problem uh and and signing so we luckily we are like on the 200 300 millisecond on test run running so that's roughly like the same kind of latency that you have on a on a standard note uh so we are pretty happy we still need to see how that's going to behave when we have different locations uh will probably go closer to half second or higher but uh we'll see in theory it shouldn't pose any problem because we are running in parallel the selection of the leadership and the consensus protocol is in parallel to the data so you have a track only for the data signing and a track only for the leader selection and they are both running in parallel and don't depend on each other for for producing the blocks and attestations a very good question the um the the set of entities that's making up the that's doing the threshold signing yeah how how long does that set last um like how long are they associated with each other for um maybe even longer than us I will say so it can last forever actually okay as long as no one exits as long as the validator is performing well as long as no takers or Risk Takers decide to withdraw their funds they will be there if everything is going correctly because why not like uh there is no we are not going to rotate change the leadership unless something is going wrong but if one of the participants misbehave one of the participants is expelled then we do these rotations and and which is called rearing of the key so we do a rearing and we you have key refreshing and okay excellent cool and is that not for the uh cab yet not for the M launch that we are preparing uh like imminently that won't be ready uh but for the next durations we will yes that's in our current road map it shouldn't be take too too long but yes plan for and is is that an expensive operation um in terms of transactions not just a transaction where you need to register the new operations so before you have a register of a list of now okay you you you you we're running thisat now I need to remove this guy and not this so in terms of transactions it's not expensive because everything happens on the background on the offchain side you know of the things on the peer to-peer layer so on the P top layer you just need to do another dkg with the resetting of the keys and then you get another group and that's pretty much it but uh most of the participants are the same so they talk to each other they just need to find another one and then add it to the group remove the other one also has some limitations you cannot do infinite res sharings because otherwise you could end up with a set with with two subsets that have majority one outside one inside and then you could have a slashing by the group that was expelled via rearing so resetting also has certain limits but yeah I mean a lot of things to to talk about that maybe for another talk because yeah does anyone else have any questions because I still have more and I don't want to take up all the time um the uh so the dkg ceremony is that publicly verifiable uh that is a very good question yes it is okay yes but it's not like Zer but yes it's publicly verifiable you can you can publicly verify where where does that like it's publicly verifiable by the like um by the by the not public okay not public not public it's verifiable but not publicly and the reason for that is because making a so when choosing a dkg we didn't we we did have different trade-offs uh and in the end we decided that making it publicly verifiable meaning means that you have to add a lot of complexity on the verification on the Zer knowledge and so on and and creating a protocol that is not that you know soundproof as like classical verifiable Saker setting so the classical is way easier to imp implement the stage and the only thing that matters anyway is that you have the public keys that you can verify that they match together that they are able to sign so if the signatures and the public key have the features that give you that they aggregate into this common thingy is because they come to the same thingy right it doesn't matter if the operators of that set created that key just because they did a Sam secret setting that was the outcome or because they did that dkg because we don't care about the process that they particularly used in the protocol it is rooted that is a dkg and not Samir SEC setting but if they want to do secretly a Samir SEC setting and do it that way is there any problem because it was Private anyway and they're going to be running the notes right so we actually don't forbid that from happening like um there is no like because there is no real damage that you can cause you're going to have deposit in most of the collateral you're going to do it privately anyway so there's no real drawback of doing that so there is no need to add the complexity of publicly verifiable other than the public verifiable information which is like I said public key the signatures aggregations and this kind of data which is public but has a publicly verifiable no we don't have that cool thank you any other questions wonderful that was excellent thank you so much you're okay [Applause] [Music]