Validator Architecture | James He

Very well. Uh awesome. So, thank you so much for joining today. Um thank you so much everyone. Uh we have uh we have James from Prism here today.

Uh so thank you so much for being here. We really appreciate having you having you join us to uh to give a talk for the protocol study group and uh uh yeah we are now in the sixth week of the of the study group and uh we are focusing uh in uh on consence layer in and in this session specifically we will talk about the validator client the architecture of the client which connects to the beacon node and actually does all the validator duties and uh yeah it's honor to have uh James from prism who is uh a developer of the client prism of focuses his work on the validated client there uh to to share the knowledge here. So yeah, thanks so much again for being here. I hope um I hope you're all ready. You can you can go ahead.

All right. Thank thanks Mario. Um so for today's presentation on validator architecture, it's going to be more of like a software engineering perspective uh rather than uh protocol specific. So I'm going to walk through uh the Prism codebase for the validator client and sort of show how um our validator client was designed. Um uh that is to say like Prism was the first consensus client.

So uh some of the code base is a little old and definitely could uh uh optimizations could be found but uh it should give you like a highlevel understanding of how this software sort of works and what's the purpose of the software. Um and I'll I'll sort of go through some visuals as well as uh some code examples of uh how it all works. All right. Uh, just a quick introduction. I have my socials here.

I I've been on the Prism team for close to four years now. Uh, and in 2022, we got acquired by Offchain Labs, who are the developers of Arbitum. Uh, when I joined the, uh, Prism team, I worked on the web UI. And so Prism was the first uh consensus client to actually give a UI for uh stakers and uh allow them to sort of um manage their uh validator keys through this UI and that's sort of my entryway into into crypto. Uh previous to that uh I worked at JP Morgan as a full stack engineer for uh close to eight years.

Um so working with Angular and Java uh but on the Prism team uh I've been uh working in Angular again for the web UI and then uh Golang for um for the rest of the code. So let's go through like a refresher on like uh what the validator client uh is. uh because I feel like the validator term is sort of like um it could mean a lot of different things. And so for uh the Ethereum node architecture uh we have uh the validator client, the beacon node, and the execution node. And uh I I feel like the term validator is sort of like overused because uh it sometimes you're referring to the validator client, sometimes you're referring to the individual validators that you import into this client.

And um sometimes you mean the like the key stores that um uh store the private keys of uh private and public keys of of your validator. And so the validator client will um import all of the uh validator key stores into this and then allow it to perform the duties of the protocol uh to propose uh blocks to attest um and and so on. And so for this uh presentation um uh I believe the the key purposes of the validator client are one to manage uh and use your validator key stores your where the JSON file that uh stores uh your private keys for your uh your validator. uh you would use the deposit CLI to go uh get these to generate these uh JSONs and then uh you would use that with the deposit contract to actually go through the activation process. Uh we're not going to go through that entire life cycle of a validator.

Um but uh it's just to show sort of um what this uh what this piece is. And then the manage and use uh piece of this is can you import your key stores? Can you back them up? Can you add settings to um the validator at a protocol level? So that's setting your fee recipient.

That's uh adding your graffiti um and and so on. and then also to provide some functions to actually use your key stores to sign uh sign uh different uh messages uh that's required by the protocol and then of course you want to be able to remove your key stores from the validator and maybe migrate it to another uh validator client as well as slashing production. And I'm sure that I'm missing some things in this list, but um uh we can all categorize that as managing and using your key stores. And of course, the second part of what this validator client software does is it allows your validators to perform the protocol duties. And uh to perform these duties, their API calls to the beacon node.

Um and there is a beacon API uh where you would perform these uh perform these duties and we'll go through that. Uh so just to re reiterate uh what I'll be going through is specific to the Prism validator client. uh the validator client architecture um is not something in the specs. Uh so the duties that it performs and some of the functions that it has uh are part of the consensus specs but each uh validator client um is is sort of uh different across the client teams. And it might actually be something nice to do to try to like evaluate what are some of the differences and where uh some uh clients can sort of optimize.

Uh like I said, Prism was the first one. So like some of the codebase is is pretty old and I'm spending some more time uh of evaluating um some key parts of the of the codebase to see if there are improvements in readability or um trying to resolve some edge cases uh with startup and and things like that. Okay, let me see if I can zoom in here. This is a highlevel view of the prism architecture. We'll start from the top here.

Uh there's these two boxes uh validator and external. Um this is just show showing that uh the validator client um all of these things all these boxes are part of the validator client. And then uh the things that fall in the external bucket is not part of the um validator client software. Uh so these are other services that it can connect to including the beacon node. And uh I'm going to go through each of these uh components sort of individually uh at a high level.

But um uh for prism uh you can start with a prism.sh file uh which uh is just like an easier way to access the uh prism binaries for uh the validator client. Uh so for Prism specifically uh we have two separate binaries for uh the validator software and the beacon node software. Some other client teams just have one binary. Um and uh you can sort of turn it on in different modes.

Uh maybe that's something that we'll do eventually, but uh right now it's they're separate binaries. Um and uh we sort of access the code uh through um uh validator.go. And I'm going to go through it. It's it's a little hard to see here, but I'll I'll go through that.

And uh we This is the entryway. You'll import the configs. You import your flag options into the system. we have the main validator client that orchestrates uh three different services. And so um for our services we have uh like a monitoring service uh for Prometheus.

We have the validator service which is um the primary service that executes all the uh the protocol duties. Uh we have a RPC service which is more like um uh representative of a API service. Uh this hosts APIs um that lets users uh talk to the validator uh the validator client um through uh REST APIs or G gRPC. Um for the Prism code base uh it was sort of developed before the beacon APIs existed which is all uh RAS based. Uh so we actually have two uh types of APIs in uh in our system.

We have a gRPC and we have uh REST. Um yeah. So the gRPC uh the RPC service hosts the key manager APIs. Those are the APIs that let uh external users sort of access the validator client. And um it will then go tell the validator service, hey, go update these things.

And we also have the wallet uh at the top here, which is what um Imprism manages the keys. And the the wallet concept is something that's sort of specific to Prism, but all clients have um their their way of managing the key stores. And so uh for Prism, it's this wallet and then we have a key manager um inside of that. And these key managers, they can be local. So you can sort of store your keys where you're running the uh prism validator or you can uh have it uh connect remotely uh to something like uh web 3 uh serer and then to perform the actual protocol duties uh it's just calling the beacon API uh on the beacon node that So that's sort of uh at a very high level what um the valid our validator client does.

Uh and we're going to go through each of these components individually. Okay. So let's let's start off here um at the beginning where we're just importing our configurations. Uh that includes like the beacon chains configurations. There's uh different ones like mainet minimal and we have end to end and then we also have all these flags because the software runs um as a co command line interface.

So you just provide all these flags um and uh the validator client imports that. So what does that look like in terms of the code? I'll I I'll go ahead and open up this here. So it's a little easier to actually see. And this is all in Golang.

So I apologize if it's not that familiar to everyone here but um should be easy enough to read. Uh we have the start node function. This lives in um cmd validator main.go here. This is sort of our entry point into uh the prism validator client.

uh we have uh this instantiation of new validator client here and then we uh uh just start it up and so uh I'll sort of jump into what is happening in this So for the Prism validator client, we sort of have two different initialization modes. Um uh this eventually will will become one to sort of make it more uh more clear. But there is like a specific setting for if you're uh starting the validator client with uh web um with with the website activated versus just using the CLI. Uh we'll just go to the CLI uh to sort of show what what that looks like. So when we're starting up uh we're setting up some of these uh some of the wallets uh which in Prism again is to manage your validator keys.

So it's sort of like a wrapper object that uh can interact with something remote or interact with uh something local like your local directory where the keys are stored. And for Prism specifically, we actually um take the uh the keys from your key store and then put it into like a new key store that just contains all of the keys that you've imported. Initializing the database. The database will hold information for slashing protection. Uh so what your validators have done already as well as um some uh setting information that uh you can use to actually configure your your your validator.

Uh stuff like your um graffiti or like what what address do you want your um your fees to go go to? if you're lucky enough to have your um validator uh propose a block where those fees actually go. Um uh so some of the settings are are are stored uh are stored in here as long as you don't disable the monitoring. We have the uh Prometheus service. So we're registering the Prometheus service here.

Uh and then you can see register validator service uh register RPC service. And when you start the um the validator client, uh it'll just sort of start all of the services on different threads and then um uh just monitor uh how how those go. We'll go go into the registered services now. So, uh sort of what I just showed in the codebase uh three different services that we have. Um and these again just run on uh different threads and they manage uh different types of work.

Um the register validator service does all the protocol duties. Uh register RPC service. Uh the RPC service does the APIs and then we have the monitoring with Prometheus. Uh so let's take a look at some of the the service specifics. So in go um this CLI context this is what gives you access to um the command line interface information and so this is what's used to check if your flags are set or not.

Uh so you can see here is like is this flag um the interop validators for specifically interop mode uh is this is this set and then if it is set then go set this configuration and as we go down it's sort of the same same thing um graffiti go get graffiti information. Uh if you have a web 3 signer, then like go get that information. Proposer settings. Uh go get that information and then it'll go initialize the service and then all this information is provided. You got your database, your wallet, um your API information, how how you connect there.

uh web web3 serer config whether you're using the web UI and then eventually you register the service and um this has an interface so this inside of this there is a start function and it will actually run um all all of these processes Um, let's go to let's go to the RPC service. That's like something pretty similar. You can see something very similar here. Um you can get go get like a O token um that's used for the uh that's used for the API endpoints and it's again checking all the flags whether or not these are are set and then eventually it'll go you know um set all the fields for the RPC server uh to host all the uh API related items. Okay.

So in the validator service um that performs most of the key roles uh of the um uh of the protocol and uh the most important function in this is this run function. So, if I can copy this. Let's just go to that. We have this run run function and this is the main uh function that will uh perform the protocol duties. And this first part that I'm going through is just initialization.

So when the validator client starts up and the validator service starts up, what does what does this thing need to do? Um in initializing the validator uh getting uh getting the head slot from uh from the beacon node updating the duties so that we have the information of what protocol duties that we have to actually perform. Um this is just some uh health check uh items. We have uh accounts changed which is a a channel to check whether or not you added or removed uh validator keys. We have the uh key manager which uh actually gives you access to the keys themselves and performs uh the uh key related actions like signing and then pushing proposer settings.

So we we won't talk about this for loop just yet. Uh pushing proposer settings uh will just tell the beacon node what are some of the settings that you have on your uh individual validators like what is um what is your uh fee recipient address? Uh did someone raise their hand? There is a question. I'm not sure if you want to take a pause for questions or we should leave it for later.

Whatever you prefer. Uh, sure. I guess we can we can take questions for what we have so far. There's actually a request if you could zoom in, please. Oh, zoom uh zoom in here.

Yeah, perfect. Thanks. Okay. Yeah, that's much better. Cool.

Um, and while we are at it, any questions so far? Anybody would like to ask Jim something, feel free to raise your hand, speak up. Yeah, Shash. Uh, hello. Yeah, James, I wanted to ask that while we were setting up the database, while we were initializing it, like uh uh like who is providing this database service?

like is it the is it the prism client or is it like the or or is the data being stored in the like uh in the protocol level? This is just uh local. So this is just your own database. This is not like um this is not like the beacon state that's sort of like shared across uh the system. This is just your like a normal database.

This is we use Bolt DB. Um, and that just spins up locally and you just store all of that data locally. I hope that answered it. Any any more questions or I'll keep going. Okay.

I'll I'll just keep going then. Um, go ahead. Oh, yes. Can you hear me? Uh, yes.

Okay. Yeah. You spoke about the validators client being able to um generate validators specific messages and sign those messages validators private key. Can you just go over it again with uh sorry could you repeat that last part? Yeah you said the validators client it signs messages um using the validator's private key.

So, I don't know if you I don't know if you can just go through that over again. Just a quick one. Oh, I I haven't gotten to that yet. So, uh I I'll show like an example of performing one of these protocol duties uh when we get to that piece. Um so I'm just I'm showing the validator service initialization first and then I'll um uh I'll show how uh the keys storage sort of works and then I'll show how the duties are performed.

So uh we'll we'll get to there soon. Okay. So in terms of the validator service initialization um we go into this function here and this is when the validator starts uh starts up. Uh so when the validator starts up you have uh functions like wait for chain start and this is checking against the beacon node like hey has the chain actually started uh for for us to to do what we need to do. Um wait for key manager initialization.

Uh so checking your uh prism wallet. Hey do I have my keys uh added there? Do I have any keys um uh in in that location? Waiting for the beacon node to um uh to sync uh because we can't really perform any actions unless uh the beacon node uh and the blockchain is is actually synced. And then um the validator keys themselves uh we have to wait for their activation.

So uh only active validator keys can actually perform uh duties. Uh either they're like active or um they're exiting but in some kind of active state that can um uh that can actually perform these uh these duties. And that is related to the validator life cycle. You have to go deposit then you have to uh wait for um the follow period and then they have to be voted in uh and then they'll get assigned this um this status. Uh and then we have uh like a doppelganger check to see like oh did did we already use this key somewhere else?

uh as just protection from uh from potential slashing. Uh and in this slide I'm sort of showing uh the wait for sync. We can go into that function. So what what is this function actually doing? Oh, I went into the wrong one.

That's for the mock. So, we got to go to the real one. This one. Yes. So in this we're just checking uh this node client which is uh an access point uh to do uh API calls uh either gRPC or um or rest uh and uh based on the response of this is it syncing Um otherwise just pull just pull against this API.

Um so to sort of show that let's go to this and you can sort of see oh this is just a JSON rest handler. It's a get request like go get me uh some information from this endpoint uh whether or not the node is syncing. And uh the big takeaway here is you know all these um uh these requests and duties uh are API based. So they just use the beacon APIs um uh to get this information and uh perform uh the needed tasks. So that's just to show uh briefly what uh validator initialization is.

Um so once it goes through all of this your validators are active you know that the chain is synced you know that uh you have like a good connection with your beacon node uh and then it can move into the uh the next uh piece to actually perform these duties. But uh uh before we go to that uh let's try to understand a little bit more on how the keys are actually accessed the wait for key manager initialization um and how uh keys are sort of managed and stored locally. So, I'll go copy this. So again in in Prism uh this is Prism specific uh you have to create a Prism wallet before you can import um import keys into our system. And so we have this wallet object and um the wallet will have things like what is the directory of the wallet and where are the accounts saved uh locally and um because we have a lot of the different types of key managers.

Some are local and some are remote. we have a key manager kind and then of course there's a password for the wallet to actually access the wallet. So when you start up the uh the validator client, you're asked for this uh wallet password uh that allows the software to actually access the uh the keys. Otherwise, um it won't have access. So again, this is going back into the wait for key manager initialization.

Uh whether you have a uh a wallet or not. And if you do have a wallet, uh go initialize my my key manager. And what what is the key manager capable of? So the key manager has several different interfaces which give it access to uh different functions that uh can utilize those uh key stores. Um so we have the public keys fetcher which is just to get the public key uh public keys of the key stores that you've imported.

we have uh the serer which is actually signing some message. So this function will let you pass in some object and then it'll sign it and then it'll return you the signature. Uh we have uh the key change subscriber uh which is um just to see if there's any changes with uh if you remove the keys or if you um you know imported new keys. Um and then you know uh there's deleter but there's there's all these interfaces that let you um actually work with your key stores through this key manager. And again the key store it sort of just looks like this this JSON file but uh this is uh our go representation of it.

Uh this should match uh with the JSON files that you get from the deposit CLI. And then let let's go through this example for the local uh accounts sort of what what this looks like. So this this function just lets you go import um import a new account into uh into our system and then let's go to local. Yeah, you can see these are some of the steps that we have. Now, not every uh validator client will do it this way.

This is more or less specific to to Prism. Uh but it should give a good sense of how some of this is managed. Um so, uh copy the in manage uh inmemory key store which is sort of all of the the keys. update the copied key stores with the new keys and then save the um the updates to disk and then re reinitialize the uh the account store which allows everything else in the system to access those keys and then return those the status um of whether or not this was uh successful. And it's just taking these key stores.

It's just taking these key stores and then taking the passwords for your key stores and then and then adding it. And this is just in terms of local usage. Uh now you might um be more uh uh like maybe your company was uh is doing staking or something like that. in which case this isn't exactly safe because whoever has access to your validator client software also has access to your key stores which um uh is probably not good. So uh in that case we have the remote key manager where instead of storing these key stores locally uh you use this web hook to um to remotely sign uh those different uh requests.

And let's go open this link. So th this is our um remote key manager and uh it just follows the same uh interface as the other key manager. So it gives you access to all those functions. Uh but uh in terms of the remote key manager, it will it will use sorry got to go find that function again. This uh get sign request JSON.

So instead of uh signing it locally, it will go create this request and then it'll send that request um to the remote signer. And this is to illustrate like these are the types of requests that you can get. And then um all this is doing is it JSON marshalss the the request. So you you get the request information and then it it's just mapping it to this um uh go representation of the of the JSON object. Um, so this is just setting it to like a string.

And then once it has this object, it it does um it it will do an API request. Let's see where is it. Oh, sign. S sign. I'm going to the wrong one.

Ah yes sorry. So we got internal sign and then you you can see this request is just going to this request path and then it's it's sort of your like standard post post request to to that remote serer to to do those tests And that's sort of what it looks like to actually uh request uh something to be signed. Uh but we'll go through like a case on an actual duty and where this signature is actually used. So now we went over um wallets and key managers and sort of how those keys are stored. We'll jump back to that run function and go a little bit lower to uh show performing the duties.

So, we're we went over all this update duties, push proposer settings, and then we get into this big for loop. And this is um where all of the tasks in Prism are done. In other clients, uh they might work slightly differently. uh some might be subscribed to the uh events API from the beacon node and then instead of having a for loop like this they would be triggered through via the events. Some other clients might uh separate the duties into their own individual services and um sort of run that um separately like they'll have like some proposer service and they'll have a attestation service but for Prism we just have this for loop and this for loop uh once you have your updated duties um there's this slot slot ticker here.

Um so every slot this all of this stuff will run and then um internally it'll have some some checks whether or not it actually has to perform this or not. Um so like update duties is really only on uh the epoch start um or if you don't have any duties on your uh valid validator client already which means you just started up. And um if we go down here, this is where the important part is. Uh so we get the roles uh for your validators at this at the particular slot and then we perform these roles. So what does that look like?

This is where um all of the different validator protocol um uh duties are are performed. So the beacon node tells us, oh these val these particular validators that you have have these duties and um and now at this particular time for this particular slot you should perform this duty. And what I'll I'll show is the uh proposed block uh as as an example and I on this slide it's just sort of showing the same same stuff. So let's go back here and go through an example of proposed block. So the validator client signs the randal reveal.

Uh go get me my graffiti information that I have locally. Um, and then go request a beacon block uh using the randow and uh and my graffiti here. The beacon node will then go request the execution payload uh which includes all the ETH1 block information. That's all your transaction information, um, all of those things. And then the execution client will return your, um, your payload.

Uh, the beacon node receives that and then finishes building your block and then um, uh, retrieve the beacon block here. And and this entire process that I'm showing here is is for local uh block building. But uh uh you know you can also have um like a remote block builder uh with uh with me and uh that's uh that would look slightly different than this but instead of the execution client here it would be like the the remote builder. Um, once we receive the beacon block back, we use the validator key store to sign the the beacon block. We checked the database if there's any slashable offenses um uh with uh this test like did did we already do this before?

Um and then uh in Prism we build this uh generic block type um so that we can uh go propose the block and and send it back to the the beacon node and then the beacon node will broadcast that block and we'll we can sort of see the same thing through the code. So we have the proposed block function and that block uh this this function was called in the perform tasks and uh you can sort of see go like hey go sign the uh rando um go get me my graffiti. go call the beacon node to get my beacon block based on this information. This is the request information and then B is the returned response from the beacon block and so uh we have this uh sort of wrapper here uh so that we can actually sign it. So we have WB here.

We sign the block. Um get the signature signing route. Build the sign block. It's just wrapping it. check if there's any uh uh possible slashing offenses against what was saved in our database.

Just wrap it in this generic assigned beacon block. And uh this is this statement is sort of specific to what happened after um after DAB because you're when you're proposing a block, you also need the blobs. Uh so you you got to go add the blobs to to this as well. So this this is just a task that we need to do here. Um and then once we have this this wrapper object this generic sign block then we can actually propose the block and then the prop proposed block is again just um just calling like it'll just go call the uh specific endpoint I scroll down here.

Yeah. So this endpoint is just a post request sending sending all of that block information. So that's just to show like what one of these tasks would look like. Um and we also mentioned the the signing the block which is uh sort of under the hood. It's just going to the key manager and then calling that sign function on this object.

Okay, so there's two extra slides for just talking about some other features in our system. One is the key manager APIs and you can go to it here. And uh we probably messed up on the naming here because it should just probably be called the validator client APIs, but we called it the key manager APIs because that's the primary purpose of of the APIs to manage your keys. And it has all these API uh functions that you can call against your validator client. um to get information about uh your particular key.

So you have your uh you can get your fee recipient go get the gas limit and the gas limit. This is specific to if you have like a builder setup, like a builder configuration, your uh your graffiti, and then you can um do the uh uh local key manager like list all your keys, import new keys, delete keys, or have like a remote one where it's the same thing but for remote. And then we have the web UI. Uh so for Prism we actually have um like a UI it's sort of in frozen status uh right now. Um uh we were about to remove it because we didn't think people were using it but I guess people are using it.

So if you have an opinion on web UI, please feel free to reach out to me. Uh we can figure out a path forward for this whether or not we um can actually simplify it and then just uh keep it or or not. But uh the web UI it's just through Angular and then under the hood it'll use a combination of the key manager APIs and some Prism um specific APIs uh to actually manage your keys and get and collect information. So this is This is just stored through this function initialize routes uh with web handler and then this web handler. Zoom in.

Oh, that's not it. That's the wrong one. I'm getting lost on this. The web web handler is just here. And so it's just um using the built uh Angular project uh and serving that All right.

And uh we are getting to our last slide here, which is just a review of the architecture and uh a reminder that um it's it's really meant to do two um two tasks. uh manage or use your validator key stores and then perform the validator protocol duties. And uh we walk through um not like in great depth on all the intricacies of um how certain uh duties are performed or other considerations like uh this is the genesis slot so we have to do things slightly differently but it provides like a um higher up architectural view of how our software runs and how our software is designed. And this isn't something that is in the consensus specs. This is sort of up to uh the implementers to decide how you want to organize these things um in the best way that uh your team can manage this.

Uh and in our case, this is uh sort of our initial design and you know, we'll keep uh iterating on it to see if um uh certain things should be changed. Uh and this is where the client teams have more flexibility um on their own implementations. And this also allows uh the client teams to do things that are outside of the uh protocol per se. um things like adding the web UI and uh like a remote serer and uh other types of plugins and maybe some teams will use it for uh other chains that might need other information that needs the software to run in a different mode. Um, but uh yeah, I think that's that's all I had for for you guys today.

If there's uh any any questions otherwise uh maybe I'll hand it back to Mario. Yeah, thank you so much, James. Very well. Uh yeah, it was really great. Awesome.

Um yeah, thank you so much. I think we can Yeah, we have ton of place for questions. So folks, if you have any thoughts, any questions, feel free to raise your hand, feel free to ask anything. Yeah, we get around 35 people doing the talk. So I hope we can we can get some insightful questions.

Yeah, feel free also maybe uh if you have further questions about Prism about later in general, I think it's also a great opportunity. Uh, hello. Thank you. I wonder where does the um station um attestations are also in the perform duties. So if I can just go to that.

So under validator client runner.co [Music] go and then perform duties should be a little bit below here or perform rules. So like submit attestation is here. We have uh submit aggregate and proof is here. And then in validator client test.

go Go. We have uh submit at test station. Thank you. No problem. Yeah.

Awesome. Um any more questions, folks? Yeah. Shane. Hey James.

Um, yeah, I was thinking about how like EPBS, you know, the instrument proposed builder separation is going to try to replace me boost with like in protocol bu builder proposers. So will this change um how validator clients interact with proposers currently like how you know block production is coordinated? Yeah, basically just curious how like prism is preparing for EPBS. You know what kind of refactoring might need to be needed between a validator client and beacon node. Yeah, there's a lot of changes.

I guess I'm not totally familiar with the branch, but there is like a EPBS branch for Prism. Uh I mean uh POTUS and Terren are uh some of the uh proposers of of all this. Uh so there's changes in uh uh like the timing um like in um in this submit at test station I believe uh like here we have wait one/ird uh or valid block um so it's like waiting one/3 into the slot and and So with EPBS I believe uh some of the this timing changes. So uh there there would definitely be changes on uh some of these functions based on the hard fork that includes this. So there would be some like if statement here that's like say checking like is this the fork that um is this the fork that uh uh is that includes EPBS or is it before that and then uh do diff do things differently there backwards compatibility stuff.

Yeah. Yeah. Thanks. Yeah. Very well.

Um, more questions feel free to free to ask folks. Anything goes. Yeah. Lori, I want So my question is, can a single VC be used across like can it be used across different clients? Say I've used it on Circle.

Can I use the same key reason? Yeah, that's a that's a good question. So, uh, for for Prism specifically, we don't currently recommend um using the Prism validator client with other clients in production just yet. It would be nice if others tried to test it out, but uh for Prism um we because we were the first uh consensus client, our system was designed slightly differently and we use gRPC which the gRPC API calls are slightly different than the beacon API calls. So, we've done a lot of things to uh try to enable uh REST um in in our validator client.

There's a flag that turns it on. Uh so, by default, it'll use uh gRPC. Uh but that is still sort of going through uh like a testing phase and um there are still optimizations that we're doing to make it on par with our G gRPC implementation. Um and in fact I I have some open PRs right now to to improve that. But it has to do with how some of the system uh caches things.

uh like one thing that's expensive is uh getting the validator's status. So like only if your validator is active can you perform this specific task. And uh not all of our code paths are optimized so that it uses the same a validator status. like sometimes it's it's like calling the beacon note to go get the statuses again um when maybe it doesn't need to. So there there are definitely improvements that we're working on.

Um but it it it's it was all because of our migration process from gRPC to to rest. But for some of the other uh clients, it should be able to run uh with a different validator client and different beacon node. So I think Lighthouse validator client with a Prism beacon node should be possible. Okay, thank you very much for that. I think another question I will have is um can I use a single validator key that I've used on say on prison and I use it on another client as well.

It's the same uh it's the same key store. So it's it's the same format. Um for Prism because we store it in the Prism wallet. You just need to back it up and then it'll return to the regular key store format that you can import into other clients. Yeah.

Thank you very much. Okay. Awesome. Uh thank you, Glory. And uh do we have any more questions?

Any more thoughts for James? Yeah, sure. Yeah, I was curious um if you could talk a bit about some of the incentives or um potentials for slashing for a validator just to go a bit more into like the economics of like why you would want to run one or even like how you would be selected as um being the guy to propose a block things like that. So I guess I h I haven't really prepared for like protocol specific questions but um uh the protocol itself will go select um uh we'll select the validator and like from the prism client perspective it's just getting the the specific duties uh that the uh the protocol call selected on the beacon node side. So from the validator perspective, it doesn't know anything about the uh the incentives or anything like that.

It's just being told like hey go like this is your your task now go perform your your duty and like in in the process of performing your duty uh you would go call the beacon API for some more information uh that's that's specific to your validator client. Um but in terms of the uh slashing uh component uh your validator client maybe maybe you were like load balancing your um your system and like you've collected some information locally and you've stored that in your database and for some reason your validator when you're calling the API it's giving you back information to make your validator perform the same task again and so in that case you're checking the database hey like did I already do this thing and uh in terms of this did am I violating the the protocol by uh by perform by performing this duty again so uh in terms of like protocol incentive stuff the validator client tries to be dumb for the most part like I think for most if not all client teams. If if it's not all, it should be all. The validator client should be sort of like a uh dumb to the protocol design. It should just um sort of call the the beacon node and the beacon node will will will determine all of those other things.

Um the validator client will just give your uh keys access to to performing that that particular duty. Got to just do your job. Separation of concerns between separation and val. Yeah. Awesome.

Um, any more thoughts, questions, comments in one? We still have some time to go and 30 people here. So, Oh, I just noticed the cat in the picture. That's so cute. Oh, thanks.

I have I have Oh, I mean, love the baby, of course, but like the bonus kitty is great. You, dad, and and two cats. Yeah. Any Yeah. So, so maybe uh less technical question like how are you handling being a core developer and a dad and a cadet at the same time?

like like from the perspective like uh what is it like like comparing maybe to other more regular uh you know uh corporate experience like what is it like to be uh working in the Supreme Court? Yeah. Oh yeah. Yeah. That that that that's a good question because uh I came from JP Morgan which is a very different culture than than uh working in in crypto.

You sort of have to be a lot more um independent. I I think um actually being core dev uh and and being uh a dad is is nicer because uh core de developers have a little bit more flexibility. It's totally remote. Um in in my case um so uh in terms of off-chain labs, there's uh employees across 19 countries and we're only about like a hundred people. So it's it's not a very big uh company.

Um Prismatic Labs was even smaller. So like when I first joined as a Athereum core developer, it was only on a team of 10 people. Um but I think it uh has given a lot more flexibility. Um and in terms of culture, I mean it's a lot less meetings, which is which is always nice. you you you can focus a lot more on work.

Um, but I guess the skills that I learned in corporate uh sort of still apply. I mean there's there's still politics in in Ethereum core development and um uh there's yeah th those those kinds of aspects that uh you know working at a big company sort of also uh teaches you. Uh but for working in the Ethereum space I guess it's a little bit more free. you have to sort of uh think on your feet and uh you're not in the bubble of just your own company like you try to collaborate with people outside of the company. Um you work with uh people at the foundation, you work with other client teams that are at other companies.

Um yeah, so that's that aspect is kind of cool. Yeah. Awesome. Thank you. Uh yeah, definitely like it's very collaborative and open.

So um we have uh Joshy. Yeah, go ahead. Yeah. Hi. Thanks for the uh talk, James.

My my my question is also a little tangential, but I I wanted to ask you what you think of the idea of the beam chain specifically, like as someone who's put so much like effort and love into working on the beacon chain. Yeah. I uh I don't think the beam chain like invalidates um the like the current client teams. um we're all invited to the beam chain calls and um I think it's important uh especially down the road that the beam chain is not just there to um replace the current client teams but sort of um maybe add additionally to because the the beam chain client team members are um are usually like uh uh new individuals in interested in uh Ethereum core development and they come with a lot of uh great new experience especially in the ZK space uh which is which is great but in terms of the uh consensus protocol itself there's all these different little like exceptions that aren't specifically written down in the consensus specs that are implemented in sort of like learned over time um on the current consensus teams like things like like the genesis slot like what do we do there and like there are certain cases around uh how language specific uh systems will deal with errors slightly differently which could result in a consensus failure. things like uh in Golang if it if I perform this specific function it might throw an error but from the spec perspective uh you're supposed to know op that even if you uh receive that error.

So like specific things like that is learned over time from the experience of the uh core developers that are working on the uh client teams right now. Um but I don't know overall I'm uh I'm bullish on this. It's it's always good to have people more interested in core development uh even if it's like a different aspect of it. Um, I think we're on like the third generation of core devs already. So, there's been like a lot of predecessors that have worked on these client teams and and leadership within these client teams have sort of shifted over time too.

And yeah, this this succession plan for uh for Ethereum implementers is is important for the ecosystem. Yeah. Cool. Thanks for sharing. Very well.

Yeah. Uh thank you so much. Um yeah, we have a space for another question if anyone wants to ask. Otherwise, maybe we can put it up here. But uh yeah, any more thoughts?

Anyone? So, okay. Yeah. One more question. Sure.

Uh, yes, James. So like uh trying to like uh get into get into the repos of client of Prism like what would be like good on boarding strategies or the potential issues that uh uh the new onboarders might work on? Um, yeah, I would say like most client teams were really short staffed. So it's hard for us to sort of handhel handhold uh contributors um even though like sometimes we we want to the best contributions uh is usually like oh I've taken a looked at at this specific piece of code um this is why I think it's wrong uh creating a PR for for that adding unit tests for Um and then uh those are usually the the PRs that uh get merged in through like external contributions. Um the the main piece is again a lot of reading, reading the code, looking at the specs again uh and actually running the code um to to see if your hypothesis is is correct or not.

Um I I think that's probably the best way to uh sort of uh onboard or uh contribute to uh to the client teams to uh there's there's a lot of different ways to run the software now. Um so you can run it through curtosis provided by uh the ETH panda ops package. So you can you can actually like uh make changes to the code, rebuild the image and then run through curtosis and you can actually check the logs to see if that's uh working the way that you think it is. Um and if you don't think it's it's working correctly, that's that's where um we could probably like collaborate more. um uh as well as Prism has um like endtoend uh tests.

So uh you can do like um uh a specific basil run and it'll run this uh it'll run Prism in interop mode um and run all these different evaluators. So adding adding new tests there and um yeah that that that would be that would be super helpful. Thank you James. Okay. Um yeah thank you so much.

I think we can wrap it up here guys. It's been a It's been a while. And uh uh yeah. Uh I don't want to keep you longer from your kids and and cats. Uh James, yeah, I just see the picture there.

Um man, yeah, I appreciate it so much. Thank you so much for your talk again. It was really amazing. Yeah. Uh I learned a lot at learned a lot today.

So, uh yeah, really appreciate your time. I appreciate the lecture and uh it's been great having you around. Yeah. Thank you so much. Do we have someone else ask something?

Um, people are clapping. Maybe if anyone wants to comment, feel free. We still Yeah. Anyone wants to have any question? Okay.

Maybe. Okay. So, or was it just the clap or Yeah, sometimes people trying to clap raise their hand. But yeah, awesome. Well, thank you everyone.

Yeah, awesome. Thank you so much as well, James. Yeah, it was amazing. Appreciate it.