Unified Specification for EigenLayer Nodes

Transcript

[Music] right hello can everyone hear me right cool um so today I'll be talking about the unified oh I'm swapno I work in nethermind um I am the head of innovation Atlanta mind um and I'm working with eigenlay on a unified node spec for eigen abs's and that's what this talk is about before we talk about eigen AVS notes back we should touch a bit about eigen itself and for those who don't know what eigenlay is I'm going to do a quick 101 on What eigenlet is so eigenlayer is a Marketplace for robust security where we can leverage ethereum security for new Services how I

can achieve this is by making the validators for the ethereum itself opt into additional slashing rules and follow new consensus algorithms and opt put up their ethereum stake against some new service um by the way I'm okay I'm happy to take questions in the middle of the talk as well so if you have any questions just raise your hand um yeah all right cool um right so now that we know what eigenlayer is and we know that validators are included in this in this dynamic in this robust Marketplace uh taking a quick look into the future we can see that that's probably the case where there's going to be many AVS built on top because the validators are incentivized economically to restart their theme security and get more rewards with it

um so economically a validator is incentivized to run as many uh nodes as possible so we can see a future where the validate might need to acquire might need to run 10 or even hundreds of nodes and this is quite problematic for many reasons one of the main that it might be a centralizing effect on validates itself I'm not going to be touching on that topic today that's a topic for a different discussion what I will be talking about is the technical part of it what does it mean for a node operator to run 10 or even 100 no 100 hundreds of nodes which might not conform to One spec they might have their own unique interfaces they might do metrics collection in some manner they might do databases in some other manner they might do updates in some other Manner and this is going to be very taxing for

node operators they now have to learn 10 or even hundreds of new commands they have to keep them all in their mind they have to like figure out how metric selection for them work they might need to aggregate metrics across all of them into One dashboard setting up alerts is also another problem so in general node operators are this is also causes a centralized impact for node operators because now you need to be hyper specialized and Hyper aware and these new orchestration software might work on stuff like that cool so what is our solution our solution is a spec uh specification for node AVS software um that focuses on inter that focuses on unifying the interfaces of all operations that are node might

need to do our focus our solution focuses on solo stickers we can expand this specification to institutional circuits as well but first we want to focus on solar stickers and it's really there to optimize the experience of the orbit itself right so in ethereum we kind of have this problem as well but on a much smaller scale so there's like four like four consensus type clients five execution clients so there's only a combination of like 20 uh Parts where you can run them in even though they follow the same specification with the consensus and execution they don't follow the same specifications for the node operator experience itself what I mean by that is they don't collect the same kind of metrics even when even if they do collect same parametrics they

might name them differently the RP theme RPC methods are standard but also they have some unstandard RPC methods to put in all of them and we don't want to repeat this problem in the eigen ecosystem one more time so we've got on the problem early and we want to use our experience from ethereum to define a specification that can help us uniform that can help us standardize the experience of node operators right so the first part of this specification is the packaging um in the first instance of the specification which is meant for solar operators we are recommending they use Docker and Docker compose for the orchestration we also have made up a new idea called profiles and manifest files if you worked with the browser

extensions then the Manifest file is quite similar it specifies the version of the node software itself but also the spec that you're following it specifies things like Hardware requirements the plugins and we'll get them later what plugins are and the last bit there is profiles profiles are specific instances of a network for different profiles and what I mean by that is let's say you're running an uh an ABS which looks quite like a blockchain so there might be a testing profile or a main net profile and for tests that you might want to do some other things like you might want to have way many more peers compared to what you have a mainnet and because test NPS might go down all the time or something like that right moving on to publishing nodes we've chosen a style very similar to

Homebrew if you use Homebrew it's not all the way as in where your Homebrew formula is not specified in a turing complete language like Ruby we just specify it as a configuration file and if you look up there the the first two packages on there are mainnet and girly and in this case they are the two profiles so this AVS which is unspecified name here can run two profiles mainly in Girly there's folders underneath underneath it called alerts dashboards and panels and those are all the folders that have all the information related to monitor monitoring the node itself then there's the docker compose which specifies how the orchestration for this node should work then there's the profile which specifies the like environment variables

configurable environment variables which the CLI might prompt you to fill in once you start running a node software in this specific profile girly has similar stuff and at the end you might see a checksum there the checksum is there to verify the authenticity of the node that you download so you can make sure that the one that you download is the correct one one thing you might have in mind right now is the checksum is distributed in the same network or the same manner as the Note software itself and it could both could be manipulated with if you break TLS or you do a man in the middle attack but we have plans of putting the checksum on ethereum itself so you have the most decentralized way of in adding the checksum and checking against your node software

right moving on to the the advantages of having this kind of spec we can do seamless updates because from the node operator's perspective they can type in a command saying eigen layer update eigen da and at that point since we are running the orchestration we know how to shut the containers down we know how to shut the containers back up do the database migrations and so on and so forth plugins so ins so this is what I think one of the most important bits of our spec you can imagine that there are many instances of many abs's that we can't cover all of them so let's say there is an ABS that does data availability but from time to time it might require you

pruning the DB we can't capture all of these uh these special features of all abs's in one unified spec because then it'd be untrackable we would have to scale with every New Abs that comes around we need to like and like we need to expect all their needs before they even come out so what we've designed is a system where the AVS developers themselves can specify some utility of their software and add dynamically to the to their CLI and then rcli knows how to interact with that CLI and can smooth over the things like then they don't have to do orchestration um rcli manages all the orchestration bits and their CLI tool can manage the AVS specific operations that they might want to do

some of the use cases for plugins might be Key Management so you might want to generate Keys specific to your format um you might have a new signature scheme or something like that running database pruning enabling disabling node functionalities so yeah you can imagine like we have similar interfaces for ethereum nodes and you want to capture the same experience on eigen ABS as well the principles for the plugins that we kept in mind while designing the plugin system was that it needs to be containerized we can't let information leak from the plugins because that can create in a vulnerability where someone downloads a plugin and messes up with the operations of the AVS which might cause the ABS to miss attestations or even cause slashing for the node

operator uh no reachability and what I mean by that is that the CLI tool orchestrates the your AVR setup but your plugin should uh shouldn't have to understand how the orchestration works for it it should be transparent for now we use Docker compose but in the future here we might use um kubernetes or cubectl to manage your nodes for institutions takings or like larger setups and at that point the plugin system should be independent of that I should not expose those details to you so now what are the steps required to add a plugin next to your node what you have to do is just add the plugin in the Manifest file the CLI tool will once you download the ABS it will also fetch in the plugin it will verify the checksum and it will make sure that the plugin is

the same one that you specified in the in your manifest file using the checksum the I guess so this is like an overview of what we do for the metric specification um we've standardized the Prometheus metrics the https HTTP API and also the grafana dashboards and we are also releasing a tool for abs developers so they can make their own modular funnel dashboards so the HTTP API is quite simple is so one of the best things is that it is prefixed by the credit parameter or URL slash eigen so anything under that path should be related to the HTTP API related to monitoring and this is not a

full-blown specification but always is there filling health checks doing service management and basic checks um there's a much more bigger specification for the Prometheus metrics which covers things like rewards slashings and other AVS specific things we make sure that all levels is labeled their their metrics with the ABS name in the tag itself because let's say you have eigen underscore rewards for eigen da but you might have a similar metric for some other AVS and we make sure that we distinguish them between between those two using the ABS name itself we also allow developers to use custom metrics so there's a set of metrics that

are required and these are metrics about the CPU usage RAM usage how much Network bandage they're using and host machine metrics basically but again we can't cover all the metrics that they might use so we let them specify their own metrics and in this case we ask them not to use the eigen prefix so the benefits of this ecos for the ecosystem of this no spec in general are the fact that now we have a unified experience for monitoring nodes we have easy integration to production quality tools like promising grafana and this is great both for node operators and developers and this also promotes better transparency and better no development practices for the entire ecosystem right so the spec is out you can go have a look yourself uh we're always looking

for feedback so and there's a report Dash to it so feel free to open an issue and reach out to us if you have any questions or suggestions and now I'm open to questions if there's any I'm assuming I'll give such a good talk you now understand all of it cool I think if there's no questions then I've done my job right thank you [Music]