Introduction to SSV On-Chain Data - ETHOnline 2024

hey guys tiller here from SSV one of the sponsors of eth online 2024 in this video I just wanted to walk through one of the three bounties that we have off our grabs the one I'll be talking about today is the best use of SSV data so there is $3,000 us up for this one and two projects will be eligible to win prizes so for this video today the content that I want to go through first of all an introduction to SSV ourselves it'll be a brief one if you want more detailed introduction you can check out our other Workshop building a reaking dab on SSV which will also be uploaded to the eth global YouTube channel I want to take a talk a little bit about DBT which is the core technology of what SSV is built on I'll look into the SSV smart contracts because that is what manages all of our Onan data subgraph which is the indexer we've chosen so essentially this stores all of the information that we need and makes it usable um to build applications and such and then a code tutorial just a very brief introduction on how to actually work with this code so a little bit about us SSV was founded in 2021 we've been in M net for around a year now um and we've been in testet for two years we have our own token our SSP token which is used for paying people in the network we have a a grants program as well so if any of your projects are really good and you want to continue working on them and it's really valuable to our ecosystem you can also apply for that after the hackathon SSV itself stands for secret shared validator this is this is kind of the original name of DVT which is not known as DVT which is a distribute validator technology essentially at a high level this is the next level of staking um and if you don't know what DBT is that's fine I'll get to it in the next slide we have this really great uh Network here this infrastructure based all around DVT in this technology currently on Main net we got 39,000 validators and we have 800 plus operators which are working on the duties for these validators and within that we got 800,000 e which is like 2 billion USD at the minute so from only being on minight for a year we a really good year so far what actually is DVT and how does this work for staking in ethereum the kind of original flow or current flow is that if I am a solo sticker I will generate a validator key I can run a node with some software on it um that must always be online so I can do any duties as a validor that I must do so I can get paid and get my rewards obviously this comes with some downsides so the validator key having to be always online I'm ready to sign transactions fact that we have execution and the consensus client both all in one node means if this node goes down we can get slashed and we can lose some money DVT is the next step forward in terms of sing to make this a bit better instead of the validator key just being on one node along with everything else we can split this validator key and we can pass it out to what we call operators The Operators themselves they will run the execution the consensus and the validator client on their own noes and when it's time for a duty for this validator uh to be done it means only three of the four of these operators need to be online this has two really important things one we can leave our validator key in Cold Storage it doesn't have to be online always which is a lot more secure for us the other thing is that because we have four operators instead of just one so pretty much four nodes instead of the one which always has to be online it adds a lot of fault tolerance so the validator themselves can feel a lot more secure because if one no goes down they're still completely fine the juty will get carried out and they will still get rewards and they will not get any of their e slashed another important point to mention is that with this setup compared to the current flow we get H client diversity within the operators so because the operators can use different nodes in terms of the where their location is based um different execution clients and different consensus clients means there isn't one single point of failure you know if say there's a problem with the execution client like a bug within the execution client itself if the other operators are using some you know a different execution Clan which is running completely fine it means the duties can still be carried out and everything will still run correctly so with the SSP Network itself you're probably wondering what is our role within the DVT landscape we have our own decentralized secure permissionless and scalable DBT staking infrastructure essentially what I'm saying here in the last Slide the way we have the validator and the four operators you as either a validator who wants to stake eth or an operator who wants to run nodes in networks you can join as either per completely permissionless completely decentralized and you can either earn money as a validator with your stake de or earn money as an operator by carrying out the duties for these validators and you will earn money in um you will earn in SSV token that way this is all managed uh through an SSV Network smart contract as we can see here in this example if I'm a new validator I come along with my key I need to register my validator to the SSV Network smart contract so I will choose a number of operators whoever is looking good Whoever has good performance and then they will take it from there as they have the shares of my key three of them can sign for the transaction and we're all good to go with our sing setup so the main point to think about here is that we have the separation of roles between the validators and The Operators the validators like I said being the ones they want to come in they want to stti their e and they want to do it securely on the other side of that the operators are the ones who are running the show they have their node set up and they will make sure this all works um correctly because we have this staking infrastructure setup and The Operators have a similar thing through their whatever they way they want to do it through cloud computing or their own bare metal nodes however they want they want to run their nodes we have this really good network and infrastructure that allows either party to easily add or remove from this network so the contracts themselves there's two of them the first one is the SSV Network contract this is essentially um the contract that manages everything on SSV on chain handles validator and operator management uh two entities we talked about before the third is the account so this is essentially just a wallet that will um manage any of the validators or operators that I've signed up on the network so if I sign up a validator on the network I'll have my metam mask or something my wallet in there and that address that actually owns this validator that that would that was what um constitutes as the account also we have Dow governance on this contract so any of these decisions that are made um something like a fee a network fee being changed it must be voted on by the Dow and then that can be put in place on the contract once there's enough votes the views contract is essentially just readon functions this is just an easy way to get any updated data on what what's going on in the contract so this is useful um for things like debugging um when you want to get a quick check on what's going on but it has its limitations in terms of we can't get historical data from this and we couldn't use this within a web app because it would uh overload the RPC node so we need a different solution so that we can get all of our up up toate data programmatically three API calls and also have all the data saved historically one thing we want to think about here um with the smart contracts is the contract events that are fired by the SSV Network contract so anytime anything is done any action is carried out any transaction is made we have an Associated event for each one of those contracts or each one of those functions to give an example of what this kind of looks like I'm inspecting this register Val validator transaction that I've run um using block SEC so you can see here I've called the register validator function so in this function I've put in all my validator details and I've selected four operators that I want to manage my validator the transaction goes through okay and registers in the contract one thing that's interesting here is that this event is fired this validator added event we have some software that will'll look at all of the events get the data from the events sort it and then put this into this really complete great data set that can be used um for building applications for quering the data pretty much anything and this is what we're using for this so we are using using subgraph uh to achieve this subgraph itself is a decentralized indexing protocol used to organize blockchain data we have a bunch of functions built out uh built out for subgraph um to tell it to pretty much look at any of the events that we fire off it'll look at the events it'll extract all of the the necessary data from those events it'll sort the data correctly and it does this by using custom logic that we have built ourselves and it'll store it in our subgraph database this means means we have a really great um really usable uh database of a complete data set of anything that happens on the SS on with SSV on chin there's two ways to access this data um one of them being the playground which is what I've showed a screenshot of this is a really easy kind of plugin play like you can select the options of whatever is available to build your queries up in graph and then as you can see here you click the little play button and you get back all the data so here we were just looking at operator id10 and we just want to get the public keyack the other way to work with it is using the API so this is the programmatic way of doing it this is what I'm going to show in the code tutorial in just a minute the boundy itself best use of SSV data so it's $3,000 first place being 2,000 second place being a th000 the idea behind this is that we have this amazing uh really usable data set of everything that happens on SSV Network and we just want to see what people can build with it it's really easy to work with and use like you'll see when I show you in the code tutorial here we just want to see what great usable applications people can build using this data so now we're going to move into the C- tutorial part of this Workshop um this is going to be a very brief tutorial um essentially I'm just going to show you how to use the SSV subgraph API how to make a request in JavaScript so we can programmatically run any of the queries that we build in the playgrounds get back that data and then at that point you know we're free to use the data however we want and display it so we'll start just open my terminal here make a new directory call SSV data I'll go into that here and we're just going to create one Javascript file here uh I'm going to call it fetch data.js just going to import one library at node fetch uh so this is the this is the library we're going to use to actually make the request um to the subgraph API and then we're going to open it up here in vs code so we'll start here just by opening our fetch data.js file and we'll start off by importing our fetch command which we're going to use to run the request um also in the setup here we are going to Define our API URL um so this is where we're actually going to make the call to um so on our docks here on SSV subph um and the SSV docs we scroll down a bit here see we have this developer API section and I'm just going to take this URL here for testnet um obviously you can just take the one above for mnet if you're going to develop something on that [Music] um and then the third thing we're going to Define here is the query that we actually want to run so for this I'm just going to head over to the playground this is the this which this l can also be found on this page so this is essentially um what we can use to build up um it's a really really easy way to build a query because you can see on the right here we can just kind of Click through it um I'm just going to query operator 100 I'm going to what am I going to select I'm going to return the operator ID and I'm going to return the validator C for this click play and then as you can see in the playground we've returned this data it's got an A validator Kind of nine so what we want to do is we want to take this query and we want to get that getting output in our code so I'm just going to put that in as our query right here um okay now we're going to go ahead and Define the actual function itself so just toine an async function here call it fetch data um and we will start by defining a try catch so we want a try catch here because we want to send uh we want to make the request using fet to this URL with the query and if there's any errors we want to understand uh why there would be errors and log that back to the console um so we'll start by defining our response variable here um so this is because we want to obviously get back the response from the fetch command that we're going to use and um we want to save that so we can output uh so we can format the data and we can output it correctly so start by defining the method which is a it's going to be a post request um yeah and then we will Define the headers which uh yeah we want to set to the content type sorry content type to be application SL Jason okay that's all we need in the headers and then the actual body so the actual request itself the query that we've defined earlier and we're going to form format that correctly so we're going to use stringify here within the function we'll put it in squiggly brackets and we will uh pass in that query um okay so if that response or if that request works then we want to format it correctly so that we can I put did the console and it's readable so we're going to use this um response. Json lower case here um and if that all works correctly then we can just hopefully output this response data um now for the catch part of it this be a very simple catch we're literally just going to look for some errors I put the errors to the console um now that that function is all done we actually want to just call the function when we run the script um so yeah let's give it a go just going to use node to run the script run our fesh data.js and there we go I put it in J adjacent format essentially exactly what we saw in the playground the operator ID the validator account super fast requests really easy to get the data um obviously there's a lot you can do in terms of what the way we can sort the data how you can build the queries yourself programmatically um there's a lot a lot of options so hopefully this kind of gives you the the building blocks to to really get started with this bndy so that's it for the code tutorial now I'm just going to run through a couple of examples on what could maybe be built for this buy the first being um some account owner dashboard say I'm an account owner on SSV I have multiple validators maybe I run some operator as well all under the same wallet if there was some dashboard that I could code to and just paste my wallet in and get all the statistics about everything I own that could potentially be very nice some metrics AG aggregation could be cool so we have all these all this data here about everything in the network if that could all be put in some one place with a bunch of like charts and dashboards so we can get an overall feel and look in how the network is performing kind of like June a little bit except I guess more up to date and just completely like on track with what is going on in our contracts and then this other one I guess this will be more on like actually changing the subgraph itself rather than building using the subgraph essentially we store every time like an an operator is is changed and we update it with the new data but we don't have any historical data on that operator we don't know what it was you know what the changes it went through previously to get to its current state if there was some way to basically save every version of that that operator that we store in the subgraph and then being able to present that so we can see how you know how it changed throughout each time it was updated something like that could be very good but yeah this is just a couple examples anyway um and anything if you're interested in doing any of these the the team at SSV super happy to help with any of these ideas you have or any other ideas you have like we're just like super Keen to get people building with this sort of thing as you can see here I've got the GitHub as well this is the code for the SSV subgraph if you want to think about doing this third um idea that's pretty much it we got some links here to the docs our prizes and the subgraph itself the GitHub we're really excited for people to be building with this if you choose this or our other bundies really happy to be sponsoring eth online 2024 and yep happy hacking guys it should be good fun