DappCon 2023: The Magic Behind Trustless Distributed Validators In Diva - Miguel Prada

Transcript

okay so I'll start uh hello uh my name is Miguel Prada I one of the co-founders of Diva and the CEO of Samir labs and as you see I'm going to present here how is the magic happening behind the distributive validator sativa um so let me start with uh why we need dbd at all um and what is uh Diva so uh as the famous sentence from the sort of the mooc say with great power comes great responsibility and uh uh you can see that if you have a set of operators as in many of the staking protocols that just assign so the liquid staking only assigns ether to operators are running validators without any kind of pound these operators can unilaterally create

some damage to ethereum so they can create losses and transfer that damage to uh the liquid inake in token um so yeah if there is no collateral role which is one of the uh main criteria for many liquid sticking tokens any damage that it happens to this oper operators and to these validators gets transferred to the liquid sticking token so that is one important factor but there is also another important factor which is a single guy single person single operator can cause these damages so not only collateral is needed in order to cover this possable damages but also vbt is needed so that way not a single person can create the damage but it need to collude with more than one entity and uh

be able to create this kind of bribery damage or any kind of calization that can happen in order to act maliciously on ethereum if we don't have these kind of measures um any operator from this type of networks can act and uh create damage to the liquid sticking token and therefore get profit somehow by either leveraging uh or or doing some actions on the background so this doesn't go very well with the famous sentence from Bitcoin of T trust veryify here we're trusting The Operators of the liquid sticking token inad instead of verifying that they need to act uh accordingly to to the protocol and behave correctly so how does daa work well D.A started around two years ago when I went to hackathon with

another colleague from n and we started developing a project about DBT so the idea here was okay we want to use DBT DBT is important it's important to have uh the validators being run by multiple entities so not a single actor can damage the protocol uh but that is only one element of many so at me loves what we decided is okay when we are designing Diva we need more than that so it's not only about uh the DVT but we also need collateral without collateral even if you trust The Operators they are unbounded they can do anything so they can collude and cause damage as I mentioned before collat is an important factor another important factor will be that anybody from our opinion should be

able to join this operator Leist so no asking to the th no asking to anybody no permissions nothing if you don't have that it's not a permissionless network it's not a permissionless token it's something it's a service that you're running with a set of operators and providing other service through a smart contract but we don't want this type of close service coinbase binance we want something that is decentralized and it behaves like a protocol as we have always seen so um let's Deep dive a little bit into the div architecture and how we are doing this so the architecture starts the same way as any other uh protocol in general you have the smart contct and you have the pool of deposits and then Staker comes and wants to deposit ether which goes to the pool so the Staker is the only one that

receives the liquid sticking token and they can deposit in this pool similarly you have operators that can join the network by joining on the uh Diva smart contract so they join that I operate with a no so they can register nodes but we will talk more about this a little bit later um yeah so then you have the two entities you have anybody that can join us operator and anybody can join us a ster and we have to match them together so to do that uh D.A keeps track of all the operators that have been registered in D.A and all the noes that have been registered in D.A so those are the main entities that are going to do the operation of the protocol um and of course like the stakers stakers are also keep in track with their balances and and rewards um but yeah important thing here is to keep

track of all the nods because we will need them later to create the validators uh we'll see how how that works and then there is the Beast that we are going to get uh deep ref into the uh into it now um of course it's going to be a high overview it's not going to be highly detailed uh because we don't have time for that but I'm going to explain how using these components Diva uh uses Randomness to basically create the distributive validators and coordinate between them uh in order to be able to to create a validator key um so yeah we use basically D kgs as you probably are familiar with distribut key generation so the nodes talk to each other through peer to-peer uh this is quite a Noel uh implementation from the

team at Samir uh we haven't seen so far any implementation out there production ready for dkg over peer to-peer so we are providing one of the very first implementation of dkg over perer top that allows to talk notes to each other and be able to concentrate one uh one BLS uh key together that they can act uh so that works pretty fine and and fast and um yeah so we're going to use as I said this part of the diagram to use it as a guideline and let's Deep dive into it sorry okay so the idea here is to use the randow to coordinate the creation of this Val how we're going to do that let's go first to The Operators list and

the node list so we have a set of operators and nodes each operator in Diva can be anyone is an etherum address that you go you click on metamask raise operator down um so any address any the address can become an operator and operators have notes so each note you can have many machines think of them has machines you can have many machines and distribute the load of the validators across different entities but the important thing here is that the collateral who deposits who control those nodes is always the operator so the operator is the one that deposit collaterals in Diva and nodes always act on behalf of the operator doing the work coordinating the dkg creating the valuators and so on and yeah and each

operator needs to have many nodes this also creates some complexity because once you have many nodes representing an operator you have to decide with which one which one has to talk to which in order to create the dkg because each one is valid so we need to create additional um layers of uh coordination in order to decide when we have more than one note uh but yeah so far uh that's the idea let's go now to the randomness part uh so this is very simple but but basically uh you can have like a balance of the pator let's say you have 24 ether at the beginning on the smart contract and then someone comes and deposit another 488 so what happened at Diva well what it happens is that the balance is changing

from we cannot create a validator yet to oh now we can create two validators because we have 70 uh 72 ethers so we have two * 32 64 with this 64 we can create two validators so what the smart contract does is that it takes Randomness from pre from uh pre randow which is now on the execution layer you can take this data manage it a little bit it's not exctly purely only the prep R but we use it as a source of entropy together with all things in order to generate a few seats so we create one random seat each one of the valers that we want to create so we have two bundles of 32 eers we create two pend validator sets with these two nodes are always

monitor in the blockchain that's why in daa we need also execution uh layer connection so we need a GU or any execution client uh in order to be able to monitor what is happening on the chain and to be subscribed to these events so ns are looking at these events uh they get the messages and then they say okay now we need to to create a valuator let's see how we create it so we're basically deterministically coordinating theg thanks to the runess of the uh of the uh randow uh so what we are doing is that we derive from this seat let's say we have the seat coming from the randow uh and uh we derive the like many validators ID just

consecutively using Hing of Hing of Hing so then from a single seat you can create many unrated uh uh seats for each one of the vors you want to create you want to create 1,000 you have 1,000 times the same uh seat from the r then from there um we have two main entities on the grid cretion of the kgs we have what we call participants that whose seat and we will see now what is this used for um is generated by housing the seed of the validator they want to participate so let's say you have validator one you have validator two and one participant wants to participate in the validator one the Val depending validator one uh ID so they have to use the seed of validator one has se with

one and that's the seat that they are going to use for what for something like a lottery but we go on a little bit later and then there is coordinators which at the beginning you can be a bit shocking and oh coordinators like Iota it's not like Iota this thing is uh mostly just as uh message sender so we need someone that has gas fees on their uh like on their balance on their wallets we don't require to have uh gas fees on the like any kind of gas or ethers on the wallet of the nodes so the whole network and work as long as someone has ethers and behaves as a coordinator so they can send message to the protocol they can send message to Diva subscribe register and so on so forth so someone needs to pay for that

and of course there will be like compensation for these transactions in order to cover the the cost of these type of transactions but yeah this coordinators what they do is coordinating helping send the messages from the from the participants so these uh guy also have uh a seat they also have a number uh that needs to be used for calculating the weight what is the weight weight is just like a lottery ticket so each one of the participants each one of the noes each one of the operators have a lottery ticket they are going to receive a loty ticket based on this Randomness um and what does it help this with well it helps because you could have different coordinations you could

have uh different uh uh ways of for DS but this allow us to have a deterministic coordinating of how the DG needs to be done uh so for instance let's think that we could try to do a naive approach and say I want to create a validator always with the address only the address of The Operators so you can order them and say okay I order them by lower to higher address as if they wear a big number but then there is a problem people will try to mine and do a Prof of work to create addresses so when they register they have higher chance of receiving validator so that create bias towards the lower addresses so we need to do something a bit more tricky at the

beginning we thought okay um we can do Hing distance if you're familiar with Hing distance you have two binary strings so you can basically create like there is no way to predict it's like with X orio there's no way to predict where what's going to be the distance to a random string so if you try to use something at the beginning doesn't going to work um but the problem with that is that in the smart contract is quite costly so uh really not the best approach we also try with an exure but ended up using hes because they are the most efficient function in the smart contract so hes are even better and they are less costly so the idea here is you have the seat and you have uh so the seat for the validator I want to create

validator number one uh the SE of the validator is whatever we'll see an example later um and we have an address of an operator good um then what do we do we has them together and that's the lottery ticket of that operator so that allows them to say okay uh I have this lottery ticket my colleague has this operator lottery ticket so you know your ticket and the ticket of everyone else and the idea here is let's try to create the group with the lowest weight the lowest accumulated weight the lowest numbers so let's try to get the lowest uh lowy ticket numbers this allow us to have basically paralyzation of thek so it doesn't matter if it's the best one

it doesn't have to be the lowest maybe one of the participant is not active maybe one of the participant is not alive and be able to coordinate theg doesn't matter um as long as someone with the lowest uh set of uh lottery tickets submits to the smart contract and they able to propose something they could win so then all the notes could be active looking at each other saying okay the best set is not proposing anything I have a high chance of winning I'm going to submit this so I'll be able to win the validator receive rewards and be able to operate and because I'm active and the one that should have done it is not available so that way there is no loss at killing a dkg doesn't matter if

we kill a dkg because there are many concurrent dkg happening at the same time as alternative proposal and always one is going to be proposed and create the validator um yeah so in this case um as the coordinator say they take the lowest accumulated weight and the lowest accumulated we is the one that uh wins and this allow us to have also a unifor distribution of validator so by doing it randomly instead of selecting by addresses purely or by picking the uh operators I want to run this validator if you pick you would choose the one that you like the most you like coinbase you like binance you like uh block team you like someone that you trust but that

creates centralization so being able to choose operators create centralization points that's why Randomness is important it doesn't need to be important for the Staker where their ethers go they need to go to the network and the network needs to guarantee that they're going to be safe so in this case the random L allows to have a uniform distribution of validators across the whole network of Diva instead of centralizing in single points okay so now let's go to an example with a little bit of numbers I don't know if you can see it correctly but um hope you do um so we can have let's say uh the seeds you have a pending validator you has it and then you have the the validator ID and then with the d154 this is the uh ID of this validator that we will see later we has

the d154 with number one which is the participant's uh weight uh base right so then once we have this value we can has each one of the addresses of these operators that we saw before with the value with the see uh with the 0 5050 which is the outcome of the seat for the participant and each one receives a lottery ticket the part on the right right side of the equation is a lottery ticket the value that they have earned as you can see number one two three are the optimal set doesn't mean they're going to receive the validator not necessarily maybe number one is not available and you have uh 245 245 could be the winning set if number one is not available because it's

the second best uh option right but if they are available then one two three will coordinate a we'll create a new key and we'll submit to the contract uh in order to be able to create the validator so as you see when you add this value it gets a minimum Su compared to all the other possible combinations and for the coordinator something similar you have a coordinator weight that you calculate using again the d154 you derive that with an number zero so you have another seat and this seat is used to calculate the lottery ticket of the coordinator great so in this case oh we saw the number five is the one that wasn't on the list but this one is the one that

now is chosen to be down on the uh to be creating the the to submitting the message of the dkg proposal so as you see this is not one of the participant that we chose so it's two completely different sets it could overlap the same set of participant or it couldn't doesn't really matter because it's just a message for wardor so um in this case is not in the set of participants that are going to do the dkg but doesn't really matter because there is no nothing that they can affect all the messages are encrypted end to end so there's nothing that the coordinator can really do or infair other than just submitted messages the good thing of this is that since it's a message that

needs to be sent and uh it generates some Revenue because you're going to get compensated by it even me exraction could potentially uh add to the logic so messages from diva in order to be able to earn this little bit because it's going to be guaranteed that if you submit that message you're going to receive the compensation for it if you have chosen to be a coordinator so the general architecture here will be that you have the three notes that I mentioned before uh where you have number one two four they do the DG between them talk to each other blah blah blah um agree on a validator key and then they sent the result to the uh uh coordinator the coordinator just because it has balance under World they

send the messages so this is what we are seeing now on the operator test net of TAA who is sending these messages well coordinators that have balance are sending this message con constantly to the network in order to create validators they take the message submit it to the network and there is a time in which many proposals are coming so it's not something instantaneous you're not going to win by being the first you have a time in which people are sending messages of proposals of dgs and after that time has passed um then there is a winning validator and that winning validator will say Okay proposal number three out of the five that were submitted is the one that is going to win and create the validator so then in the next stage uh a validator is created

by the ones that won the previous time period uh so yeah and then the general architecture as you could see here uh is basically divided in two parts is the left part that we saw before where you have the creation of validators so people taking ether people registering notes uh dkg happening and the randomness being created there uh and the outcome is the yellow ball the validator so you end up with a validator after the creation of that you end up with a public key that's been registered and a validator is being assigned to that so the smart contract is the one that sends the funds but it needs the validator public key in order to register everything so Diva here Act only has a forward of message for the deposit contract and then the right side

has the validation part so after the Val is created the left part doesn't matter anymore you are just receiving duties working with your validator client and working with the ethereum clients that receive messages signs Aggregate and there is another coordination and consensus that we don't have time to talk about but yeah in the future hopefully I can I can explain more about how the right side the DBT and and coordination part for the ass signing happens uh so I think that's all from my side thank you very much to all of you for attending to nois for organiz in this event and uh yeah if you need anything else just feel free to reach out to me and uh yeah thank you to all of you