Joe Petrowski:      00:02          Welcome to Relay Chain, a podcast produced by Parity Technologies where we discuss all things; Substrate, Polkadot and Web3.

Joe Petrowski:      00:22          Today on Relay Chain we have Gautam, our Solutions Architect at Parity, and in a twist, he is going to be interviewing me, so I'm going to let Gautam take it from here.

Gautam Dhameja:     00:31          Hi, everyone. Welcome to this new episode of Relay Chain podcast. I am your host today. I'm Gautam Dhameja. Like Joe mentioned, I am a Solutions Architect with Parity. As you might have seen and heard, that there is a candidate network for Polkadot coming up very soon, or I'm not sure, by the time this podcast gets released might already be there. Kusama the network, and there are some important questions about how do I become a validator? What should I learn before doing that? What are the must haves? What are the misconceptions? And so on.

Gautam Dhameja:     01:08          We wanted to talk to Joe, who's actually also working in this direction, helping the validators get up and running and get started on these processes. He's the best person to talk to about knowing more about these things, that's why I'm interviewing Joe today on his podcast. Let's dive in and learn more about becoming a Polkadot or Kusama validator. Joe, welcome.

Joe Petrowski:      01:30          Thanks, Gautam.

Gautam Dhameja:     01:32          Let's quickly understand a little, and we'll jump right into it. I wanted to understand a little bit about what does a validator do in context of Kusama and Polkadot?

Joe Petrowski:      01:43          Yeah, I think we can kind of even go out of blockchain for just a minute here and just talk about... because validators are, they're helping the network come to a consensus. And so what is consensus? Consensus algorithms tend to be a defined series of messages that make a network of computers appear as a single computer. It shouldn't matter how you connect to the network of computers or which one you talk to, if you ask a question, you should always get the same answer.

Joe Petrowski:      02:12          This can sound a little bit abstract. But if you think about it, in something like a physical space, if you have an airplane, there'll be multiple computers, because things that have humans and then tend to have redundant systems. If you ask the flight computer, what direction am I going? It shouldn't matter which part of that network you asked, you should always get the same answer because it's very obvious to see that an airplane can only be going in one direction. And so consensus is just an algorithm that is a series of messages of how to get a network of computers to look like a single computer. That's really our goal here, and the validators are passing these messages.

Joe Petrowski:      02:48          In the context of Polkadot and Kusama, we have these algorithms that work together. They're called BABE and GRANDPA. BABE is for producing blocks and proposing what the next stage change should be. And GRANDPA is for finalizing it. I think we're going to be talking a lot about staking, and rewards, and punishments here. The main thing to keep in mind is that the reward and economics part is different from consensus. Consensus just defines; these are the actions that we want you to do. We want you to produce valid blocks, we want you to check that they're actually valid. And we want you to agree on which ones are final. Things that are bad might be signing or voting for two blocks that actually conflict with each other, or proposing a block that's not valid.

Joe Petrowski:      03:36          When it comes to staking and slashing and rewards, we're really talking about how do we respond to messages that consensus defines as good or bad.

Gautam Dhameja:     03:45          Interesting. In that case, if I understood that correctly, and just to rephrase it for our listeners, in context of Kusama and Polkadot, a validator would be doing two things. One is making sure when the time comes when you have the opportunity produced next block, and vote on finalization of the subsequent or the previous blocks. So whenever your opinion is needed you vote for a block, which needs to be finalized. And whenever you get an opportunity, because it's a round robin approach, I believe, to produce a block. Or it's a random approach in BABE, right?

Joe Petrowski:      04:24          It's both. It has a random approach with a round robin fallback, so that we can get a constant block time.

Gautam Dhameja:     04:29          Interesting, interesting.

Joe Petrowski:      04:30          I would say there's actually one more thing that I missed here, and that's very Polkadot-specific in that validators are responsible for passing messages between parachains, and that's something that doesn't exist in a single blockchain. But when you have multiple blockchains, the validators have this additional responsibility of sending messages between them and making those messages available for reconstruction.

Gautam Dhameja:     04:53          Interesting. So in that case, there are now three things that validators do. One is produce a block when you are asked to do that, vote on previous blocks which need to be finalized, and then pass messages between different blockchains?

Joe Petrowski:      05:07          Yes. And I would say we have a nuance here and that we're not really voting on blocks, but we're voting on chains.

Gautam Dhameja:     05:13          Okay, interesting. So we are considering a chain of blocks to be finalized instead of a single block?

Joe Petrowski:      05:19          Yes.

Gautam Dhameja:     05:19          Awesome. Awesome that's so efficient in terms of getting finalization.

Joe Petrowski:      05:24          So you could actually vote on a block that's five blocks ahead of the last finalized block, and it will add those signatures and votes to the blocks that are behind it, and then we can finalize all of them at the same time.

Gautam Dhameja:     05:36          If I think of it in in a different way, that is so freaking amazing, because you are actually using the characteristics of blockchain to finalize the blockchain.

Joe Petrowski:      05:46          Yes.

Gautam Dhameja:     05:47          Wow. And this is something and I just want to call out that our colleague, Ben, he actually pointed this out to me when he was explaining GRANDPA to me, so yeah, pretty cool. Now that we know what a validator does, we also want to understand a little more about accounts, keys, and tokens over here. Because before we jump into staking a nomination, like you mentioned, there are these things involved. What do you stake? How do you control that? How do you access those? How do you sign your message and everything? For that, before we move into... because staking a nomination will require a lot of function calls and messages, and so on. So before that, we want to understand the accounts and keys over here.

Gautam Dhameja:     06:32          So maybe just give us a brief about those things.

Joe Petrowski:      06:35          Yeah. Polkadot has two general types of accounts, a stash and a controller. Just know upfront that the difference here is purely semantic. It's the same type of cryptography, same type of key pair, they can actually be the same account, although we don't recommend doing that. The distinction is really only in how you use them or how we want you to use them. The stash account is something that should generally be kept offline. This would be like where you keep your life savings or large amounts of money that you don't intend to move.

Joe Petrowski:      07:06          But if you are a participant in governance or nominating, you want to be able to nominate with this stake. But you don't want to sign a lot of messages with this key because that kind of inherently makes it vulnerable to being captured by somebody else. You really only have to sign one message with your stash account, and that is a certificate. So you take the public key of another account, which we call the controller, and you just sign a message from your stash account that says, "You know what, here's a public key of another address. I want this to be my controller." In this controller account, you can put a very small amount of funds, like just enough to cover transfer fees, or I guess that would be transaction fees because not every transaction is a transfer.

Joe Petrowski:      07:48          This controller key gets to just tell the system what you want to do. It can say I want to nominate this validator, I want to validate myself, or I want to vote on this governance proposal and it has the weight of the stash account because it got permission to do that. But the funds aren't really at risk because you're not signing these messages with a stash account, you're signing them with a controller account. And only this very small amount is at risk. If you get concerned that maybe your controller account's key was seized by somebody else, you can just change it and designate a new controller for your stash account.

Gautam Dhameja:     08:24          Okay, so we have two accounts and one is called a stash account where I have the majority of my funds associated. And second account is the controller account, which is basically more like an operational account for controlling or managing operations, or like functions on the chain. These accounts are associated together by calling or by signing a call using the stash account?

Joe Petrowski:      08:50          Yes.

Gautam Dhameja:     08:50          Okay. Interesting. And then that makes the whole thing a little more secure because once you have your stash account you can literally, by after associating a controller account with it, you can just keep it aside and keep it in a very secure and safe place. And then from there on, your controller account is the main thing that you want to work with.

Joe Petrowski:      09:10          Yeah, that's right.

Gautam Dhameja:     09:11          Okay, interesting. Now, let's go into a little bit about the session keys. Because that's something really interesting. I still could not wrap my head around what they are and how they function, so let's understand a little more about them. Before that, tell us a little about what exactly are session keys.

Joe Petrowski:      09:28          Session keys are a very abstract concept at first. It really helps to talk about them just as a concrete example of how we use them in Polkadot. The more abstract--you can just kind of declare, however many session keys you want in a blockchain using Substrate, but in Polkadot we have four. These keys, you can just declare and say, I want them to be associated with some sort of message that validators perform.

Joe Petrowski:      09:57          It should be noted that these keys are not meant to be accounts. So they don't have to be the same cryptography that an account uses. They can be completely different, although at the moment, they're not. These are just for signing messages, so these are not associated with funds at all. In Polkadot we have four. We have one for BABE for the block production. We have one for GRANDPA, which is finalization, we have one for "I'm online,' which is sort of like a helper message, you tell the chain every couple hours, like, "Hey, I'm here as I'm supposed to be." And then we have one called parachain ID which helps match the validators with parachains so that they can find each other.

Gautam Dhameja:     10:36          Interesting. If I understood that correctly, we have four session keys and the basic function of these session keys is to kind of show your identity or prove your identity in different contexts. So let's say for example for babe and grandpa you want to show your identity about, "I am this particular validated for these different contexts." And then for, "I am online" like showing that I will be signing my messages for being online or for showing that I'm online by using this particular key. So that will identify me as a validator again for in the "I'm online" context.

Gautam Dhameja:     11:13          Finally, you mentioned something about parachain ID or something like that, right?

Joe Petrowski:      11:17          Yeah. This helps the parachains and validators too find each other and know who they're talking to.

Gautam Dhameja:     11:22          Okay, interesting. So, then again, basically, it's all about identity. So session keys, I would say that they are primarily for proving the identity of a validator in different contexts. And they are all separated out from each other so that they can be easily, like changed, or maintained, or like just for more control, because having four different session keys—how do you maintain those session keys?

Joe Petrowski:      11:47          Yeah. There are two general ways to do it. I guess first, you're right, like these are about linking what your validator is doing to your validator. And so, just like you assign your controller accounts by signing a message from your stash, you're going to tell the network about your session keys with your controller.

Joe Petrowski:      12:05          After you tell everybody that you want to be a validator, you're going to take all four of your session keys, the public half of them and sign that message with your controller account. And that says, "These session keys are the keys that I'm signing for for my validator, which is tied to my stash accounts." And so when the network gets a message from you, that says it was signed, a grandpa vote on a chain finalization, then it can say, this vote comes from this stash account, because it's linked to this session key.

Gautam Dhameja:     12:36          But just for the understanding of our listeners, and also for me personally, when I am having two accounts and four keys, how do I make sure that I'm not doing something wrong or doing exactly the thing that I need to do with them?

Joe Petrowski:      12:51          Yeah, this gets a little bit more advanced than maybe your normal user would do. So this is definitely focused on validators. If you just want to nominate, this is not something you ever have to worry about. The way you would generate the session keys is by calling an RPC endpoint in the actual node that you're going to be a validator on. It will generate these four keys for you and put them in the key store that is contained within the client. And it will give you back as a response all four of the public keys, and then you can sign this message with your controller that associates your node with your controller.

Joe Petrowski:      13:26          These keys can all get managed within the client. So after you do that, you don't really have to worry about it. You've already told the chain that these are your session keys, and they're in the client and your client will actually know which ones to use. It's a pretty simple example, when you first start, you just do it once, but then you can change these keys every session. And so you can generate a new set of keys just by calling this RPC and then sending this message back to the chain, "Hey, these are my new session keys," and your node will actually check on the chain, what is the most recent declaration of your session keys and it will use those. That's in its memory.

Gautam Dhameja:     14:02          Okay. That's what I actually wanted to understand, that I do not have to really manage or maintain any of these keys, it will be done for me by the node. And all I have to do is basically call an RPC, which will generate those keys for me and then return the public half of all four of them. I mean, just to put in even simpler words, I have to just pass those four public keys as parameters to extrinsic call, and then it will associate those with my controller, because the message will be signed with my controller key. And from there on, and I'm all set.

Joe Petrowski:      14:33          Yeah, that's right. There are more advanced validators who want to generate the session keys outside of the client. And so there is a way to inject your session keys into the client if you want to do that, although... One of the motivations of doing this is to have backup validators. So if you want two validators who have the same pair of session keys, in case one goes offline, the other one can pick up. We really only recommend doing this if you really know what you're doing.

Joe Petrowski:      15:00          If you're listening to this podcast, that's probably not for you. It's great that you want to be online and have a fallback, but the punishment for assigning two conflicting blocks as much higher than the punishment for being offline. If you're not 100% confident in what you're doing, you should let this be managed in the client itself. But there are the tools available if you want to generate these keys and manage them outside the client and inject them into the clients as you choose. You can also do that.

Gautam Dhameja:     15:27          For the scope of our talk and for the concept discussed in this podcast, I think we'll just keep those aside because those are advanced things. Listeners, if you want to really get into those things reach out to Joe.

Joe Petrowski:      15:40          Yes.

Gautam Dhameja:     15:41          Okay, let's move on. I want to understand a little about key management now. At this time, I understand I only have to manage my stash and controller account. The stash can be something like managed using a paper wallet itself because after signing the initial message by off linking the controller with it, I don't really need it in an operational way, so I can just put it aside.

Gautam Dhameja:     16:06          So key management is only needed, I believe, for the controller account. How do we do that?

Joe Petrowski:      16:11          Yeah, right now our keys are based off SR 25519. You kind of have to use desktop wallets or paper wallet right now, because we don't have hardware all supports, although we do have people working on Ledger and Trezor integration.

Joe Petrowski:      16:28          For Kusama, you're gonna have to manage just sitting a password and keeping this file on your computer. It's obviously encrypted. If you set a password, by the time we launch Polkadot, we should have Ledger and Trezor support so that you can manage these keys with a hardware wallet.

Gautam Dhameja:     16:43          Interesting. At the moment, we do not have HSM (hardware security module) support or like hardware wallet support, but we are on our way?

Joe Petrowski:      16:51          Yeah.

Gautam Dhameja:     16:51          Okay.

Joe Petrowski:      16:52          And then, HSM is kind of moved into the validator stuff because it's conceivable to use them for session keys, and some other proof-of-stake protocols do this. It's also not possible right now because we have four session keys and there aren't any HSMs as can handle SR 25519.

Joe Petrowski:      17:10          Part of the rationale behind an HSM is that it has... A part of the design of an HSM is that it has extremely limited memory. This is by design because it just limits the space for attackers to do anything. And so we can't really make the SR 25519 signatures, certainly not with four separate keys on there. For the moment, we don't have HSM support, although we're working on some alternatives to that.

Gautam Dhameja:     17:35          Okay. I think that will be communicated and published whenever we have that support coming up. Both for HSMs and hardware wallets, I believe.

Joe Petrowski:      17:45          Yeah. As part of our roadmap to be able to support not just the in-client management of session keys, but also external just have the client send out a payload and say, "I need this signed," and then you can return it signed to whoever you want. HSMs actually tend to provide a false sense of security because they're just kind of dummy signing articles, whatever you send them, they'll just sign it and send it back to you. And so if you did send, say, two different blocks that conflicted with each other, an HSM would just sign them. It doesn't know anything, it doesn't have any logic in it.

Joe Petrowski:      18:20          So some of the more advanced methods actually help us like SGX or just an x86 general purpose machine that has some signing logic and at that says, you know, I'll never sign two blocks of the same height or something. Everyone kind of jumps at HSM as like the first thing, but it's really not the best way to protect yourself. There are much more secure setups that you can do by implementing some logic around it.

Gautam Dhameja:     18:43          Okay. Interesting. In that case, I think just to clarify one thing that at this time that nobody is blocked, you can easily go ahead and do your key management using, for the session keys using the client and for the controller key using a desktop wallet. Or I think we also have browser extension being worked on from our JavaScript team. So I think there are options to manage your keys at the moment.

Joe Petrowski:      19:07          Yeah, and for the truly paranoid, what we're going to do is once we have our Polkadot JS, which is like our JavaScript tool and website for generating these keys and interacting with Polkadot, once we have it ready for Kusama, and I'm sure we'll do this again on Polkadot, is that we're going to sign a commit of Polkadot JS with... Parity has its own GPG key, and we're going to say, "This is a good version of Polkadot JS that you can use." You can put it on a thumb drive or something and use it in a virtual machine or a live booted machine or an airgapped machine or something and generate your keys that way. And then you could conceivably just sign your payloads like this. Put it in a connected machine, generate your payload, bring it up to your airgapped machine, sign it, bring it back.

Joe Petrowski:      19:53          There are kind of hardware wallet solutions. It's just a lot more steps than using a Ledger.

Gautam Dhameja:     19:58          Okay. Let's move on to the next topic that I wanted to discuss with you is about now getting into some details of the staking side of things and nominated proof-of-stake. And then when it comes to stake, then we have staking rewards. And then we have something called slashing as well in Polkadot and Kusama. So let's talk a little bit about that.

Gautam Dhameja:     20:19          Let's start with maybe understanding and NPoS nominated proof-of-stake a little more.

Joe Petrowski:      20:24          Yeah, in NPoS, you're going to have a list of people who want to be validators. There are a lot of people, the majority of people who do not want to be a validator, because it takes a lot of work to be a validator. But they still want to capture the inflation of the network. This is kind of the difference between proof-of-work and proof-of-stake networks, is that the only people who capture inflation in proof-of-work are the actual miners, whereas in a proof-of-stake network, depending on how the network is configured, a lot of people can capture parts of this inflation by nominating or delegating or, however the network calls it.

Joe Petrowski:      21:01          But if we focus on Polkadot here, it's nominating. There's going to be a list of people who want to be validators. If you do not want to be a validator, then you can nominate somebody. And you can actually nominate a lot of people if you want to. Our goal is to have equally staked validators. So if we want 100 validators in the network, we want each of them to have 1% of the stake that's behind the validators. We let people nominate more than one validator and we have an algorithm called fragment that will automatically distribute the nomination stake in the way that optimizes the validator sets.

Joe Petrowski:      21:41          There's really two optimizations that are taking place. What's the best combination of validators and nominators that results in the most amount of DOTs at stake? And then the second optimization is, what is that allocation of those nominators that results in the most even distribution of that.

Gautam Dhameja:     22:00          I want to understand this a little better. When you say the algorithm automatically decides how you want to distribute your nominations—as a nominator, do I have control on who should I nominate? Like, for example, let's say one thing is that the algorithm or the network allows me to nominate multiple validators. And then, let's say A, B, C and D or four validators and I want to nominate them, and I have 10 DOTs, let's say or 10 KSMs. I want to put these 10 KSMs on these four validators. Do I have the control to say that I want to give two to A, and four to B, and one to C, and then whatever is remaining to D? Or will the algorithm decide it for me?

Joe Petrowski:      22:49          No, the algorithm decides that for you.

Gautam Dhameja:     22:51          Okay, so I just have to say that four validators I want to nominate, and then these are the DOTs that I have, and then do your thing?

Joe Petrowski:      22:58          Yes.

Gautam Dhameja:     22:59          Awesome. That makes it really, really simple. I don't have to really worry about where the money's going.

Joe Petrowski:      23:04          Yeah.

Gautam Dhameja:     23:04          Okay, cool. Well, some people worry about that, but it makes it simple.

Gautam Dhameja:     23:10          Okay, now that we know generally how nominated proof-of-stake works, and even before that, let me rephrase this for our users so that for their understanding that a nominator is anyone holding tokens, can be anyone holding tokens. And a nominee in this case is actually a validator or the next validator selected for the next era, or how do we-

Joe Petrowski:      23:35          Someone who wants to be a validator.

Gautam Dhameja:     23:36          Someone who wants to be a validator. You can simply choose and decide which are the subset of validators you want to nominate and put your stake behind, and then they'll go and decide for you on where it goes and how it gets divided.

Joe Petrowski:      23:51          Yes.

Gautam Dhameja:     23:52          Now let's move on and talk a little about how do I nominate and how do I ask for nominations. Because now we have to clear two different roles. And let's get into the operational side of it. If I have tokens, and if I know that I want to nominate Joe and Joe's friend and Joe's friend's friend as three validators for my stake. How do I tell the system or tell the network that these are my three nominees?

Joe Petrowski:      24:20          Yeah, that's pretty simple. You just sign a message with the address of the validator that you want to nominate. I believe it's the stash account for the validator because the controller in session keys can change. And so that's all handled through the UI. It sounds complicated, like sign a message of the address of the validator, but in Polkadot JS, there's literally a button that says "nominate," and you can choose who you want there.

Gautam Dhameja:     24:46          Okay. In that case, it's like, if I understood correctly, that there is extrinsic call exposed, and I think it must be in the staking module in that case?

Joe Petrowski:      24:57          Yeah.

Gautam Dhameja:     24:58          Okay. So there is the extended call which you can call by using any of the UIs which are connected to the network, and then you can set your nominations. And this should be signed by your controller account?

Joe Petrowski:      25:12          Yeah, as a nominator, you can still have a stash and controller account. You shouldn't be putting your stash funds at risk here. Just sign it with your controller account that this is who you want to nominate.

Gautam Dhameja:     25:24          Okay. That's simple, that's easy, that I can nominate just by calling an API endpoint or just by calling extrinsic on Polkadot or Kusama. Let's talk a little now about rewards.

Gautam Dhameja:     25:38          We talked about staking, of course, like validators are staking for becoming a validator. Nominators are staking for reaping rewards by not even being a validator. So how do we get rewarded?

Joe Petrowski:      25:55          This is something where Polkadot diverges from a lot of other proof-of-stake networks in that the rewards are actually not proportional to how much you as an individual have at stake. They're proportional to how much total is at stake. And then within that, all of the validators get equal rewards, regardless of who has the most stake. We want to have about 50% of the network at stake behind the validators. That's our goal, so then the other 50% of the network is for parachain slot auctions. So we expect parachains to have DOTs bonded for their parachain slots, and then a small amount as liquid tokens to be traded, transferred, whatever.

Joe Petrowski:      26:39          We want 50% of the network safe behind the validators, so we just kind of have a curve from 0% at stake to 50% at stake that ramps up with inflation, or the inflation ramps up as the amount of stake ramps up. And that way, there's always more rewards as more goes at stake. Once you pass 50%, they drop off quite dramatically. So there's not much incentive to be a validator or to nominate with your tokens once this goes beyond 50% at stake.

Joe Petrowski:      27:11          Once the inflation for the network is set, however many DOTs per era that is gets split evenly among all the validators. So even if one validator has twice as much as stake as another, they're going to get the same reward. There are two motivations for this. One is kind of from first principles, validators are doing the same thing. They have the same responsibility. They were voting on things, they're producing blocks, so they're doing equal work, they get paid equally.

Joe Petrowski:      27:37          Our second motivation here is to have all of these validators be equally staked. If you're nominating someone, you'd actually want to nominate the lowest stake validator. If one validator has 100 DOTs behind it, another one has 500 DOTs behind it—as a nominator, you're going to get a percentage of the rewards. You're going to get a much higher percentage of the rewards if you stake the validator with 100 DOTs behind it. It should incense people to nominate the lower stakes validators, and that just kind of naturally leads to an evenly staked network.

Gautam Dhameja:     28:12          That is really, really interesting and cool, because in that case, I am being motivated as a nominator, and I'm being motivated to put my stake behind the least staked validator so that everybody is equal. And that also helps me get more rewards, because then I have more percentage of stake for that particular individual validator.

Joe Petrowski:      28:33          Yes.

Gautam Dhameja:     28:34          Let's talk about slashing.

Joe Petrowski:      28:40          All right.

Gautam Dhameja:     28:40          We got rewarded, eventually we will fuck it up, so what will happen?

Joe Petrowski:      28:45          Yeah, if you fuck it up, you'll get punished.

Gautam Dhameja:     28:48          Okay.

Joe Petrowski:      28:49          You have a lot of responsibility as a validator, so you're expected to honor it. But of course it varies in a lot of different axes here. This also goes along with keeping an evenly staked network. Slashes are proportional to your amount at stake. A slash is percentage-based, not absolute-based.

Joe Petrowski:      29:11          If you have a lot of funds at stake behind a validator and it's misbehaves, in absolute terms, you're actually going to lose more than a lower stakes validator. When it comes to larger validators, these two things together, you can see kind of lead to the conclusion that you should be running multiple validators instead of just staking behind a single one. But if we focus on slashing here, there are a few categories of misbehavior of varying severity, kind of on the light side would be just being offline.

Joe Petrowski:      29:42          You're supposed to be online, that's kind of your job, but also we recognize that shit happens and every once in a while, you lose connectivity for a couple minutes or something. I think we actually give you like one freebie—if you miss a session, it's okay. If you miss two, you start getting slashed. It's really small, I think like, .01% or maybe .1% of your total stake, as a little slap on the wrist. And then it actually forces a new election, so you get kicked out of the validator set for the next era, which starts immediately and then you kind of have to ask to come back in one later.

Joe Petrowski:      30:21          Punishments kind of increases as you do worse things, so I think like double signing a block, that means signing two different blocks that conflict with each other, I think that's like a 10% slash. And then things that attack the network. Like voting on a chain that conflicts with a chain that's already been finalized, these can be slashed up to 100%. Part of the motivation behind these three levels is the offline thing, mistakes happen. The double-signing thing. It's like you can be running good software, but maybe you made like an infrastructure mistake. You set up two nodes with the same keys, and they accidentally sign different things. You really shouldn't do that, so you get punished heavily.

Joe Petrowski:      31:07          If you do something like vote for a block that conflicts with something that's been marked final, this shows you've actually modified the software. It's in the Polkadot implementation, not even to import a block that conflicts with the finalized chain. If you import and vote block conflicts with this chain, you're clearly not running the standard software. It's not just like a screw up, it's you're actually trying to attack the network here. That gets slashed the heaviest.

Joe Petrowski:      31:38          There's another dimension to this, which is the coordination. If, say 20% of the network goes offline, it's not going to be slashed .01%, like if just a single validator goes offline, because it looks like a coordinated attack to slow down the network or even halt it. It could be a coordinated attack, it could also just be negligence like, if all of the validators but their nodes in the same data center or something, we want to avoid that. We want validators to be conscious of where they're putting their infrastructure and make sure it's really independent so that we don't have large chunks of the network going offline together.

Gautam Dhameja:     32:17          Okay. Let me understand that a little better, because I think what you mentioned is, and please correct me and jump in, if I rephrase it incorrectly. When I get rewarded, I get basically rewarded equally along with other validators as a validator. And as a nominator I get rewarded as per what I've put in, in a particular validator. For example, if a validator is getting 10 tokens as a reward, and if I have a staked 10%, then I get one token from this.

Gautam Dhameja:     32:49          But when it comes to slashing, it's kind of different because I don't get slashed equally, because it's me who is making the mistake and not the others. So I will be slashed on the basis of percentage. And then there are different scenarios to be considered like, if this is just missing a block production, then there are different things. If it is just missing, for example, a vote, then there will be different slashing. And then if I'm trying to attack the network in a way that by signing two blocks or something like that, then this will be a completely different blunder altogether.

Joe Petrowski:      33:26          Yeah.

Gautam Dhameja:     33:26          Okay. So then slashing is really, really more serious thing, and it's really important to play fair here because otherwise I'm going to lose a lot of money.

Joe Petrowski:      33:36          Yeah, and you should be careful who you nominate because nominators get slashed with their validators.

Gautam Dhameja:     33:42          Oh, okay. So nominators, they will also be seeing the effects of slashing?

Joe Petrowski:      33:47          Yes.

Gautam Dhameja:     33:47          Okay. And is it also in the same percentage?

Joe Petrowski:      33:51          Yeah, so it goes across the nominators and the validators.

Gautam Dhameja:     33:54          Okay. How do I know if somebody has been already slashed or if somebody is not playing fair? For example, is there a dashboard? Or is there a plan for something like that where I can go and see, oh, these are the current validators, they have this kind of reputation, they have been always online or not, and so on. Is there something being planned in that direction?

Joe Petrowski:      34:15          Planned, certainly, which may even be outside of Parity, but we definitely expect to see some kind of forum or dashboard that reports on validator activity. Because like the slashing stuff is all on chain. It emits the events so you can kind of replay the chain and see what happens. I don't remember if the slashes actually get stored. I mean, you can see the the actual account balances change, and there are events that get emitted for the stuff. I don't know if we plan to do it, but yeah, surely these things emerge.

Gautam Dhameja:     34:45          Yeah, I'm coming from the fact that this will be interesting for nominators because like you mentioned that you should be aware of who you are nominating. Then there should be a way of knowing that, like who I'm backing for example, a criminal record kind of thing or something like that where I can say that, look, this guy is not doing good. He has been slashed so many times, he has not been sending "I am online" messages consistently.

Gautam Dhameja:     35:12          There should be... I mean, of course, if nobody's working on it, then this is a good thing to do, I think.

Joe Petrowski:      35:18          Yeah.

Gautam Dhameja:     35:18          For the listeners. For the listeners, like if somebody is willing to pick something up in the Polkadot ecosystem, this could be something.

Joe Petrowski:      35:25          Yeah, for sure, especially if you don't have access to the resources for like the actual... Because there's a lot of physical infrastructure in validating. If you don't have the money or the physical resources to do this, and you're interested in staking and validating, this is totally something that you can just do as a software project. It's really like it's in the interest of the good validators to create a website like this to show that they're online.

Gautam Dhameja:     35:50          Absolutely. Absolutely.

Gautam Dhameja:     35:51          We covered staking rewards slashing and the NPoS side of things. We also discussed a bit about key management, the different accounts keys and so on. And then we started with the validator introduction. Now, let's actually move right into the process part of things. We eventually wanted to go with with this particular episode of the podcast that when somebody wants to become a validator, what he should be doing. Till now we were basically building up to this part, understanding different concepts and how things work and everything. But now, let's get into the real work stuff. Like if I want to become a validator, first of all, how different is it for me as compared to other proof-of-stake networks?

Gautam Dhameja:     36:35          If I want to become a validator for Kusama or Polkadot, should I be considering something different or should I be expecting something different here?

Joe Petrowski:      36:43          I think from a setup point of view, it's pretty similar. I mean, DevOps and infrastructure are kind of the same everywhere. There are a few differences like whether you're an HSM or not, but overall architecture is pretty similar to other proof-of-stake networks. There's nothing wildly different, which we actually want, because we want validators who are competent at validating. Right now, this is a very niche and new industry, so the most experienced validators out there are validating on other proof-of-stake networks.

Joe Petrowski:      37:19          For the most secure setups, it's kind of nice to have something similar and these principles like being online and not double signing, these are kind of universal across all proof-of-stake networks.

Gautam Dhameja:     37:32          Okay. In that case, listeners, do not worry, there is nothing really, really complicated going on here. Let's jump right into it. What should I do first, if I want to create create a validator node or deploy a validator node in my choice of data center, then how should I begin? What would what would be the first step?

Joe Petrowski:      37:54          I was just talking to someone at the Web3 Summit one or two days ago who's coming up with kind of one-click deploys for this stuff. Hopefully, you won't actually have to do that much. But if we get a little bit into what that one-click deploy would be, you're probably looking at some sentry nodes in the cloud. What a sentry node is, is that you don't want to give away the IP address of your actual validator because it'd be very easy to DoS it and just make it go offline. It doesn't really give any profit to the attacker, it just makes you lose money because you get slashed.

Joe Petrowski:      38:31          You don't want your actual validator to be exposed to the network, but has a lot of work to do. There's this concept called sentry nodes, which are just full nodes running in the cloud, and they're the only ones who have permission to connect to your validator. So your validator is not on the public Internet. It only has like a VPN connection to some of these full nodes in the Cloud. And these could just be like EC2 instances in AWS or Azure or something. They'll forward messages onto your validator.

Joe Petrowski:      39:00          If somebody tries to attack one of these by sending a million copies of the same message, the sentry nodes will check, and they're only going to send one copy of this to the actual validator. If these sentry nodes got attacked, it's very easy to spin them up. You can load balance or auto scale, whatever, that can help distribute the load among different sentry nodes. And then once you go beyond that, there's the actual validator. We recommend running this in a private data center or if you have the skills yourself on your own server infrastructure. These connects to the sentry nodes, and eventually this is where you could actually add a third layer for like a signing machine or something behind that.

Joe Petrowski:      39:43          But from a very high level about all that, I think we can say, verbally without going to like a pencil and paper is that there is kind of like a front line of sentry nodes that live in the cloud that can be load balanced and scaled. They're the only ones who have permission to actually talk to your validator and request things to get signed, and your validator sends the messages through those. That way nobody else on network knows where your validator is.

Gautam Dhameja:     40:07          Okay. And my validator can be anywhere in that case, like, in the same data center, in a different one, in a different cloud operation, cloud provider, or even on my laptop.

Joe Petrowski:      40:18          Yeah. I mean, we don't really recommend putting the actual validator in the Cloud, because then you're kind of leaving your key management up to somebody else, which, in most cases... I mean, this is kind of off blockchain topic. But a lot of small businesses or even medium businesses are like I don't want to put my information on the cloud, because how do I know it's secure? It's like Microsoft and Amazon are just better at securing their data centers than you are, probably. But in this case, because a validator is going to have, literally, in Polkadot, millions of dollars at stake stayed behind it. It's perhaps something you don't want to leave up to the cloud if you consider it really mission-critical, then maybe you want to have it on private data center or running it yourself.

Joe Petrowski:      41:07          But it is, of course, from a DevOps perspective. It's possible and probably even easier to run the actual validator in the cloud.

Gautam Dhameja:     41:13          Okay. I will leave that to the listeners who want to be validators. Let them decide where they want to put it, but I think their recommendation is pretty clear that they should be considering running them themselves, or maybe in a non-cloud data center or private data center, or if they want to just keep it simple, they can run it anywhere they want.

Joe Petrowski:      41:35          Yeah.

Gautam Dhameja:     41:36          Okay. Now that was more about the infrastructure and topology, like there will be sentry notes, they will be talking to the validator, and so on. But I think there are some key concepts here that we spoke about earlier, and then let's just bring them back because they are relevant to the process.

Gautam Dhameja:     41:52          If we start from scratch, let's say if the first of all, I will need a stash account?

Joe Petrowski:      41:56          Yes.

Gautam Dhameja:     41:57          And then I need a validator, sorry, controller account. Then the step would be to connect or associate these accounts with each other by calling an extrinsic. Signed, this call should be signed by the stash account. And that will be like connecting these two accounts together, so that at this point in time I have my two accounts.

Joe Petrowski:      42:19          Yeah.

Gautam Dhameja:     42:20          Then I download the Polkadot or Kusama binary, the node binary, and supplier chain spec file to it, I'm assuming?

Joe Petrowski:      42:30          Yeah, and if you're on Polkadot or Kusama, that chain spec comes with a binary.

Gautam Dhameja:     42:35          Okay, interesting. Cool, even simpler. So I download the Polkadot binary, I run the node and sync it with the network. At this time, I have a full node running, I have my two accounts, and it's syncing with the right version, already synced. And now what I do is I create my session keys by calling an RPC?

Joe Petrowski:      42:54          Yep.

Gautam Dhameja:     42:55          Now that will return the public parts of all the session keys. Then I take those public parts and call and extrinsic again, which should be signed by my controller account. And this will associate my controller with my session keys?

Joe Petrowski:      43:09          Yes.

Gautam Dhameja:     43:10          Okay. Cool. So at this point in time, I'm all set with my accounts and keys?

Joe Petrowski:      43:14          Yeah, I think the one thing in between is that before setting our session keys on your controller, you also sign an extrinsic from your controller that says, "I want to validate."

Gautam Dhameja:     43:23          Okay, okay. So that happens before?

Joe Petrowski:      43:25          Yes.

Gautam Dhameja:     43:25          Okay. I have also shown my intention to be a validator by calling a validate function of the staking renewal. So now I can actually, like participate in the next election whenever that is happening?

Joe Petrowski:      43:36          Yeah.

Gautam Dhameja:     43:38          If I have enough stake, and if I have enough nominations behind me, then hopefully I will be elected as a validator. And if not, what should I do if I don't become a validator?

Joe Petrowski:      43:51          Keep at it. Yeah, I mean, if you're running multiple validators, you might just have to shut one down and put more of your stake behind a single one. Otherwise, I think that's more of a social thing. Find more people to nominate you.

Gautam Dhameja:     44:07          Okay. Basically, that's what I wanted to understand because the validator set will change every...

Joe Petrowski:      44:13          About a day.

Gautam Dhameja:     44:13          About a day, and then I can try to become a validator for any any election that I want.

Joe Petrowski:      44:20          Yeah.

Gautam Dhameja:     44:21          Okay. Now, I became a validator and I started validating, and then, for example, I want to go offline. There is slashing for being offline, so I should not be doing that while I'm a validator. But at the same time, the infrastructure that I am running my validator node on or maybe because of some other reasons, I want to go offline for a bit. I want to upgrade things or do some maintenance or migrate everything to a new and better place, and so on. For that, I will be looking at some downtime, because that's how infrastructure works. What should I do?

Joe Petrowski:      44:59          Yeah. If you need to go offline, then you have two options, basically. One is to set an extrinsic. It's called Chill, which says I want to stop validating right now. I think you'll still have to finish up the era that you're in. But then in the next election, you'll just be removed from the validator set, and then you can go offline, no punishment or anything. And then, once you've done your upgrade and come back online, you just say, "I want to validate again," and you're up for election in the next election.

Joe Petrowski:      45:31          If you don't want to have any dropout of the validator sets, then what you can do is just have a second validator running, set the session keys on that validator. Tell the network that you want to use this new set of session keys, which I think we've covered the double-signing thing quite a few times, don't put the same piece in two different nodes.

Joe Petrowski:      45:52          Tell the network which session keys you want to use, and then your new validator should pick up and you can update the old one and switch back. I think you would have to connect it to the same sentry nodes, because this gets into the networking, but the validators have this DHT of where all the other validators are and how to find them.

Joe Petrowski:      46:15          Of course, this can change as you add and remove sentry nodes, the DHT is updated, but I think you're probably better off if you can just keep the same sentry nodes, so everyone knows where to find you.

Gautam Dhameja:     46:27          Okay, just to rephrase the first and the simpler option for our listeners is that, if I have to go offline, if I have to pee or something like that, then it's pretty clear that just by calling the chill extrinsic, I am showing my intention not to validate in the next era. And then, as soon as this current era is over, I will be removed from the validator set for the time being. And then I can go offline, do my thing, upgrade my infrastructure and everything and then come back and apply for being validator again by calling the validate function.

Joe Petrowski:      47:01          Yeah.

Gautam Dhameja:     47:02          Okay. I think that covers the process part that we discussed that we will want to set up our account. We want to download the binary, create the session keys. We want to show our intention to be a validator, or actually it comes before that, because you mentioned clearly that after downloading the binary and having the node syncing, we want to first say that we want to validate and then we want to generate the session keys and associate them with the controller account.

Joe Petrowski:      47:30          Yeah.

Gautam Dhameja:     47:30          Okay. That makes us a contender to become a validator in the next election. And then if we get elected, we become one.

Gautam Dhameja:     47:38          Cool. Last and final bit that I have here is just to clarify a few things for the listeners. It's about misconceptions. Because there are so many new concepts, and this is the first time we are actually talking in detail about these things and going to publish them in the open domain. I also want to talk a little about misconception like what could be or what are the misconceptions here with these concepts? And if you want to just let the listeners know that this is... you should avoid that.

Joe Petrowski:      48:10          I would say, like we covered the number one misconception is just that the validators gets equal rewards regardless of stake. I feel like I have this conversation almost every day, because it's just different than other proof-of-stake networks.

Joe Petrowski:      48:24          The other, I wouldn't call it a misconception, is that in GRANDPA, you're voting on chains, not blocks, which we also mentioned, is just very different from other algorithms and blockchains. It's not block-based. It's chain-based.

Joe Petrowski:      48:38          I don't think there are many others. I mean, the actual infrastructure part is pretty similar to other, I mean, non blockchain just normal infrastructure.

Gautam Dhameja:     48:48          I think the primary misconception is only about the slashing and rewards. Rewards are basically equally divided among the validators and then their nominators take the amount proportional to their stake in a particular validator, while slashing actually happens in percentages, and we have covered that previously.

Gautam Dhameja:     49:08          Yeah, that's the major difference, and that should not be taken as a misconception. It's actually a thing and you should care about it.

Joe Petrowski:      49:18          Yeah.

Gautam Dhameja:     49:18          Okay. I think that covers a lot of this thing. Finally, I would like to ask you if there are any do's and don'ts for potential validators, if they should be looking at something and they should not be doing something at all?

Joe Petrowski:      49:31          Yeah, I think the number one do is, do take it seriously because there will be a lot of funds at stake. Proof-of-stake networks, not just proof-of-stake networks, but blockchain networks or even consensus networks are completely economic. Their security is based on how much is at stake, not really much else.

Joe Petrowski:      49:52          We expect validators to have a lot of money at stake behind them. And so it's not really like if you want to play around, play around on testnets, and experiment there. But make sure you're actually thinking of seriously when you're on mainnet and have your setup audited or something, like don't take anything for granted.

Joe Petrowski:      50:13          As far as don'ts, don't mess up.

Gautam Dhameja:     50:17          Don't be offline.

Joe Petrowski:      50:18          Yeah, don't be offline, don't double-sign blocks, and don't do bad things like vote on chains that conflict with the finalized chain.

Gautam Dhameja:     50:27          Okay. Cool. I hope listeners you have listened to that and you got that clearly. Now, I think that's pretty much it from the questions that I collected from our team and from myself as well. And hope this is useful for our listeners who want to jump into validation on Kusama or Polkadot in the future.

Gautam Dhameja:     50:49          Thank you so much, Joe, for sharing all this information with us.

Joe Petrowski:      50:52          Yeah, thanks for having me on the podcast, Gautam.

Gautam Dhameja:     50:54          Yeah, cheers.

Joe Petrowski:      50:57          Thanks for listening to Relay Chain. We'd love to keep in touch.

Joe Petrowski:      51:00          Follow us on twitter@relaychain or email podcast@parity.io. Our team at Parity include some of the leading peer-to-peer networking developers, consensus algorithm inventors, blockchain innovators, and Rust developers. If you want to learn more about our work or want to work with us, visit our website at parity.io and sign up for our newsletter at parity.io/newsletter.