 All right. Good afternoon, everyone. My name is Kaushal. I am from the Nimbus Client Team. Hopefully you'll know what Nimbus Client Team is, but if not, I'll talk to you about that. I support Nimbus Client Team with their ecosystem development efforts, which means I get to go out and talk to end users who use the Nimbus Clients or other Clients for that matter and understand what their experience is today and what their expectations are of the future. So in this talk today, I should start to use the clicker as well, actually. All right. There we go. Yeah. So I just wanted to share some of my thoughts and experience talking to a lot of the validators, right? Whether they are centralized exchanges, whether they are the professional node operators or individual users. I just want to share the feedback that you get when you talk to these validators about what's the future of the client experience. Like, what does the client experience need to look like in the future? As you can see, I titled my talk, Validating Made Simple, Light and Simple. It may be light, but it's definitely not simple right now. So that's something that we definitely want to fix in the future. Let's talk about Nimbus a little bit. So Nimbus is an Ethereum client. It's a consensus client that you can use right now. It's an easy, efficient, low resource intensive or less very efficient, essentially, stable consensus client. So you can use the Nimbus client with any other execution client if you're running an Ethereum node. The story behind Nimbus is obviously around lowering the barriers to enable participation in the Ethereum network. And we are very specific about the words, it's the Ethereum network, not Ethereum in general. You want more participation in the Ethereum network, truly see it decentralized further. The reason behind that is also the next slide, which is it's part of the status network portfolio of projects. Many of you will recognize the status network project or the status app, for example. Many of you will have that on your app, on your phones as well, and hopefully are using it. But the story is, status started back in 2017 with the mission to create a decentralized peer-to-peer censorship-resistant chat application. But as we started building it, we realized that there is a lot of work on the infrastructure side that needs to be done. And that includes building the infrastructure for enabling a completely decentralized peer-to-peer messaging, storage and compute. And that is where some of these projects actually fit in. If you want to know more about some of these projects, please pop by the Nimbus booth on level three, and we'll be happy to talk through the details of each of these projects. But there is a common thread that runs across all these projects, and that is to enable true decentralization, right? And the focus on privacy and censorship resistance. And that sort of theme flows through to Nimbus as well. So, when we talk about the future client experience, right? It needs to be in the context of who the users are. And both the current users as well as what we see the composition of the, you know, valid data set to look like, maybe a year or two down the line, or future, in future in general, right? And who are our current and future users? So, our current and future users can be broadly classified into categories. It's the individuals, or you can call them the solos takers, right? And the professional node operators. Now, there are some other, you know, you might call them customers or segments that are in between, but broadly speaking, you can put them in these two, one of these two categories, and we can work through the details as we work through the presentation. So, let's talk about each one of them. We will talk about the professional node operators first, and then we will talk about the individual users, and we'll see what the similarities and differences are in terms of their expectations of using a client to run a validator. So, professional node operators, like who are these? Let's look quick show of hands for people who have staked their ETH with, let's say, a centralized exchange, or LIDO, or rocket, not rocket pool, but any of the LIDO or centralized exchanges, for example. All right. A few hands here. That's good. That's good. We'd hopefully see more hands when we come to the individual segment. But professional node operators are an important part of the network right now. Like it's not a segment we can ignore, right, whether we like it or not. They are here. They do offer an important service right now, and they are a large part of the network, that needs to be taken seriously in terms of their expectations as well. So, in my role, I have had the opportunity to speak with about 12 to 15 node operators in the last six to eight months. And it's really interesting when we talk to them about their setup, the history as to why and how they have set up the node operations, that we understand, you know, why they've chosen certain clients and why they've chosen to work with certain clients. And in that process, we've learned a few things which is really interesting. Some of these node operators, in fact, most of these node operators are quite large, right, by ordinary means. I mean, in terms of comparison, they run anything between two and a half to seven, eight thousand validators. That is a lot of validators, right? And these are individual node operators, maybe 20, 30 of them. I don't have the exact count, but I suppose that's somewhere close to 30, 35 node operators total across some of these liquids taking protocols in general. They tend to operate from specific regions. They generally are a registered entity in these regions, which means they are governed by the law of those jurisdictions. And they're trying to obviously scale up through the liquids taking protocols, but also directly trying to find customers who would like to stake with them, right? And the other aspect that is really interesting is that they're trying to also serve the needs of institutions operating from the same jurisdictions. Why? Because they understand the jurisdiction, they understand the regulatory aspects and the nature of business in that jurisdiction, and the institutions in those jurisdictions seem to have a inclination to use and work with node operators from that region, right? So it kind of makes sense that they are sort of becoming a channel for the institutions to come on board. So that's another point, another reason why node operations and node operators in general as a segment are an important segment of the network and they need to be looked at in that regard. Let's look at what the node operators actually look at in terms of performance or what they prioritize as the characteristics that are important. The first is the uptime, right? Now when you're running 7,000 or 8,000 validators, uptime is really important. You can't be down for hours. It needs to be up and running. There needs to be a fair degree of failover redundancy in the system. It's like it's a significantly professional or sophisticated operation that the node operators actually run. The second being reward performance, which is extremely important, so the choice of client is also based on, you know, is the reward performance good enough? And finally, operating efficiency, like you don't want to hire too many people to run the operations as well because that impacts the profitability of their operation in a way. So these are some of the factors that node operators think about when they think about their business in a way. And this is important because this feeds down to what they look at in the client when they select a client, right? So things like stability of the client is extremely important. Things like reward performance. How does the reward performance of client A compare to client B? These are factors that are extremely important to node operators. Factors like fit with the current setup. This is something that is extremely important. Why? Because each client is slightly different. And this goes back to Danny Ryan's presentation on day one, where he talked about diversity of perspectives. And each client team takes a slightly different perspective on how they would like to architect the client. Now, when it comes to node operations, node operations like similarity, homogeneity in the client architecture so that it fits with the way they have started to operate, right? So it's really interesting that there's a huge push to try and figure out how to make the clients actually fit and work with the current architecture of the node operator and the future and in the direction in which this architecture is actually evolving. Other factors are really important, such as release communication and the rhythm. So how good and the quality of release communication, the rhythm of the release communication, and the ability to contact the team, the ability for the team to turn around when there are issues and challenges. And of course the testing rigor and the variety of testing that the team actually conducts before the release goes out. So these are all very important factors from a node operator point of view, right? And as a client team, we have to take these into account as expectations of a potential large set of customers, right? Who use these clients, essentially. Now, what does desired client evolution look like from a node operator point of view? It's basically much more flexibility in how they would want to use the client to make it work with their current setup and much more interoperability. Interoperability because it's not just the client software that is used. There are other pieces of components of software that are actually used in running a sophisticated node operation, right? So interoperability with all of these components becomes really important when it comes to selecting a client and working with a client. All of these factors on all these discussions are really important because if we want client diversity in the network, then we have to somehow make sure that we meet these requirements, we meet these challenges so that we can see greater diversity in this segment of validators, which is primarily the node operators, which we are talking about here. So a little bit about what Nimbus is trying to do to address these issues, right? So Nimbus started when it went into production in 2021. It was constructed as a very simple easy client to use. It had a single processor beacon node setup. It had validated duties that are performed by the beacon node itself, which means you don't need to go and set up a separate validator client. So this was really easy for anybody staking from home. However, as we've talked about it previously, a lot of node operators actually started using some of the other clients, which are architected slightly differently, which means a separate beacon node, separate validator process, and the ability to mix and match between these components. So it is an expectation that Nimbus also offers something similar if Nimbus is to be used equally well in this segment of validators, in this segment of customers, right? So there are a few things that Nimbus has done over the last six to eight months, things like supporting the Nimbus beacon node with support for vouch and the lighthouse client, which we have now in place, and the Nimbus Web 3 signer remote signer interface as well, which is in place. So these are things that are really important for node operators, not as much for somebody who runs, let's say, a single validator from the home. But these are expectations from a node operator perspective. The one big requirement that was missing, the missing piece, I suppose, was the Nimbus validator client or the ability to split the client. So having the ability to use the separate beacon node and the validator separately and use them with other mixing and matching it with other client components essentially. Nimbus did not have that so far, but we have it now and it's available in beta, it's going out of beta into production and ready for mainnet very soon. So these are all the components that have been built over the last few months, last few, last six to eight months to enable Nimbus to be better suited for this large segment, which is the node operator segment. That is not it, though. There are some advanced features which Nimbus is working on, some of the validator client features that are really interesting for node operators. And I'm talking about these because these are factors that are important to node operator segment, which need to be taken into account when we think about the future client experience as it evolves because the client is the one client that is used by both individual users and the node operators at a professional level. So the advanced validator features are things like they are inspired by the shared secret validator research and it addresses risks like rogue employees, malicious actors or infrastructure failures. Even in the current setup where you have validators running through remote signers, infrastructure failures can still bring down the operation in a way. So that is one area or risk potential risk that the node operators are still exposed to. There's always a risk of rogue employees because if an employee has access to all the key keys, they can actually hold the company to ransom, right? And you don't want that when you're running 7,000 validators. So these are some of the factors that are really important for to address from a risk management point of view. There are some features that Nimbus is working on in terms of what the advanced validator features that would look like that would address some of these issues. And part of this is about splitting the sysadmin teams into multiple teams that have only access to part of the keys. Like no one person has access to all of the entire key set, I suppose. And distributing that the portions of those keys across several different infrastructure providers potentially. The challenge also here is that this is extremely complex. I mean node operations itself is complex and then on top of that we are overlaying organizational changes that you need to bring about. So this creates an additional layer of complexity, but it's a trade-off, right? It's a trade-off around do we want to actively manage that risk versus sort of live with this risk as a node operator. And in this regard, there are a few possible solutions that Nimbus is exploring including kind of a new remote key store where each item is sent to multiple Web 3 signer instances instead of just one. So there are some of these things that Nimbus is exploring which will add much more capability to the validator client which is what the node operators have been looking for for a long time. So overall, you can see where the expectations of node operators, how the expectations of node operators are changing with regards to the use of the client, right? And how they see the evolution of the client experience. Now this is definitely not what individual customers want, right? Like as an individual, if you want to run the node, you're looking for simplicity. And so it's almost like pulling the direction in which the client should evolve in a different direction totally, right? Compared to where the node operators are seeking for the client to evolve. Quick question before I can't go back unfortunately, but I just quick show of hands for those who are running a node from their own homes. Wow, that's definitely more than people who are staking through liquids, taking protocols, or exchanges. So that's really good to see. Hester and Keele from the team ran some research very recently and the feedback is quite interesting from individuals. There's a lot of potential, there's a lot of interest, but they're all held back by a number of challenges, particularly around lack of easy access to documentation, lack of uniform documentation. Multiple clients have multiple guides. You need to shuffle across these things. It is not easy. Multiple Discord channels, for example. So there are a few requests that came out when they ran this research, right? One of the first is, is there a no command line option please, setting up a validator, right? Believe it or not, all the validators you set up right now, no matter which client it is, it's all still command line, right? So a lot of users and users who are interested in running validators who are not very tech savvy are still looking for a non-command line interface to set up the validators. A fair ask, right? The second challenge, obviously, is don't have the 32 or 68. So how do I participate? So this is a huge idea in this segment of individual users, which is around that you need 16 to 32 to participate in the network, but there could be other ways to participate in the network when you're not validating, and we'd like to explore a few of those in this talk as well. And finally, as I said earlier, the information is scattered across forums, across different guides, across guides that are created by champions in the community, and then Discord channels. So it becomes difficult, if not impossible, to coordinate and to be across all of this, especially when there are multiple releases going out for the client. Professional node operators have the bandwidth, the capacity to be able to deal with this, individuals don't, right? So there's an absolute need, and I know the community has been asking for individuals to step up and take on the responsibility to run more nodes, run them at home, but there are real challenges, and from a client team perspective, we definitely acknowledge that these are challenges that need to be addressed. Now, let's give credit where it's due, right? So credit to Rocketpool, to Stereom, to Dappnode, who have all stepped up in a way to offer some solutions while there is a gap. Dappnode, Stereom offer ability for you to spin up your own nodes, right, on your own hardware with a UI, so you don't need to necessarily use a command line interface. So these are absolutely positives, and there's an option to use Nimbus across all of these operators. Rocketpool, of course, are very popular amongst people who want to run a node from their own homes, whether that's a full node, whether that's a mini pool, and again, Nimbus is extremely popular as a client of choice amongst Rocketpool users. Nimbus is doing its own bit to contribute to this effort, right? So we completely acknowledge there are challenges here that need to be addressed, and we have some views on how this can be addressed. The first thing is abstracting the complexity away from the end user, right? End users like to be taken on a journey if you can give them a wizard and follow the journey, follow the wizard to get to set up a validator successfully, easily, and be able to monitor that in a simplistic fashion, then that is what the end user would like as an individual. So one of the key tenets here from a client evolution point of view for individuals is abstracting complexity away from the individual, and this takes the form as far as status is concerned. We've talked about, let's say, stadium and app node, but status is heading in this similar direction. The status network team is actually planning to integrate the Nimbus client inside the status desktop, which will give users the ability to spin up a node, manage it through the status desktop application. So this is one of the things that Nimbus and the status team are working on to address. Second one, let's talk about the elephant in the room. Who's recently set up a node? Quick show of hand? All right. You had to set up one execution client, consensus client, or probably even beacon node and a validator client. Let's talk about the two components individually, and then possibly an MEV set up, right? That is like four steps. It's too complex, right? For individuals, when we're talking about no command line options and presenting a simpler UI, walking through setting up four different clients with four different guides, potentially, or components at least, is complex. And this could get even more complex if it's not checked right now. So we need to do something about this. And from a Nimbus point of view, one of the things we would like to do and we are working on is a unified execution plus consensus client, or actually an execution client that works really well with the consensus client from Nimbus. So a Nimbus execution client and a Nimbus consensus client together. There will be ability to use these clients independently and interchangeably with other clients as well. But I think there is real benefits if we can simplify the setup of a validator and take the user on a journey where you set up your execution client and consensus client simply in the same process, rather having to switch between things. There are other ways to participate in the network. So the light proxy, this is something I want to spend a bit of time on. I think I'm running out of time, but I have enough time to cover this as well. So the light web proxy is something that Nimbus has recently released. And this is another way to participate in the network. Participating in the network doesn't only mean attesting and validating and creating blocks, right? Participating in the network also means taking responsibility and checking, verifying where you're getting your data from. Can you trust that data? Should you trust that data? If you should not trust that data, you should at least verify it, right? And so light web proxy gives you the ability to do that. You can basically set up the light web proxy on your phone, right? And instead of trusting the endpoint, let's say the wallet trusts the endpoint that's set up for the wallet, instead of trusting the data that's provided by the endpoint, the light web proxy can actually intercept that call to give you an example. If you make a call, you want to check your balance on the wallet. The wallet makes a call, you know, get balance, get it balanced. The light web proxy can actually intercept that. And the light web proxy connects to the light client network to keep track of the head of the chain right now, or the state, right? And then it requests a get proof separately from any of your API providers to check the state route against the balance that is supplied. So now, if let's say in FURA, you use MetaMask within FURA, and if in FURA comes back with the balance, the light web proxy can actually verify whether it is true or not, whether that balance is correct or not. So there are all these things that can be done to improve the security and health of the network that don't only mean validating and staking. There are things that individuals can do on their own to improve their own security, the security and trust in the balance that they see in the MetaMask wallet. And these are things that are possible now, right now. So on that note, I would also like to say my colleague, Eton, is going to present about the light clients tomorrow. So if you're interested in the light client and the light client proxy, please do make sure you attend his talk. It's quite fascinating to see the actual demo as well, if you can show that. And finally, in conclusion, I'd say the client experience or evolution of the client experience is being pulled in different directions, right? More modularity when it comes to node operators and simplicity when it comes to individuals. So the task for client teams in general isn't easy to balance these priorities. But I think I can speak on behalf of Nimbus that I think from a Nimbus point of view, there are certain things that we have planned which should hopefully address a number of these things for both these major segments of validators, because both of them are equally important at this stage. On that note, I'll conclude. I'm happy to stay in touch. My Twitter is lifelines, and you can also reach out to me via Telegram and other channels using the same handle. Thank you. Any questions? Second row? You know, you're close enough, you could probably yell if you want. Hello. Thanks for the sharing. I'm just curious for the better user experience, were you like thinking about how to provide infrastructure as code to set up the infra like Terraform or HelmChart, this kind of thing? So if I understand correctly, I think are you asking whether or not Nimbus would supply infrastructure? Is that what you're asking? Sorry? Infrastructure as code? Right. I think the primary goal for us at the moment is to make sure that we can tick the boxes that we have planned on the roadmap, right? So these are things that we must address over the next six to eight months. It could be one of the things we could consider, absolutely, but yeah, I wouldn't say more about that than that at the moment. I think for us, it's important that the users who end up using Nimbus, but that's directly using Nimbus as a validator that they set up on their own home environment, whatever that looks like, or use Rocketpool, Stadium, Dappnode, or any other hardware providers to set up their client or have, you know, or use as part of professional node operations at scale, that they have the flexibility to run it the way they like it, right? So I don't think we'd like to mandate anything in particular, but the guide does cover different scenarios, depending on who wants to set up in different ways. Great, thank you. Let's...