Meeting Time:
April 1, 2020, 10:00-11:00 Beijing time
Conversation:
NIP199-Marks Proposal: PoD Block Generation Penalties (by MarkAU) was approved on March 12th, and it is recommended to adjust the current block punishment rule. Click to see the introduction of the current block penalty rules Since then, Natoshi1 (Dustin), MRH2 (Ravin), GoogleNAS (Racho), SNZPool (Yuan Shuai), NASAU01 (Mark), InfStones (Sili), StackOfStack (Shestovsk) and other nodes have proposed 7 different proposals, click here View.
Goal:
The nodes in the English community talked about the proposed modifications to the block punishment rules.
Summary:
The basic rules of PoD should be a simple simple solution that can be integrated onto the existing structure.
In order to ensure the stability of the mainnet, if a node misses a block, it must immediately affect the node’s stability index. However, the freezing of the NAS can be extended with the medium severity penalty being executed after 10 polling cycles of the node being offline. This allows for a sufficient amount of time for nodes to restore their service
During this meeting, a consensus was met and will enact the 10 polling cycle delay for medium severity penalties. In the future, there will be 2-3 proposals submitted on Go Nebulas. The final proposal will be confirmed via the first NAX governance vote on the mainnet.
Discussion (note: due some participants missed the call for different of reasons):
Becky: Gave an overview of the meeting with the Chinese community the prior day. The conclusion reached during this meeting was that the penalty mechanism should be similar for now. If the solution is too complex, it may introduce unforeseen issues/bugs into the penalty mechanism. If a node received a medium penalty, the node’s stability index would immediately be affected however, NAS would not need to be freezed immediately. Instead, medium penalties would incur a NAS deduction of 5% only after being offline for 10 consecutive polling cycles.
In the near future, the governance committee would vote on a permanent proposal made up of 2-3 suggestions via on-chain NAX voting. The selected rule would become the permanent solution for the penalty mechanism.
Mark: I agree that we need to keep it simply and not too complex. The initial concern pertained to nodes being unfairly penalized based on unforeseen issues such as datacenter downtime and service maintenance. I agree that a simple solution is good. as long as it can scale with the network. I do think the penalties should scale based on the overall stability of the miner or what you were saying earlier that initial outages would not be immediately penalized. I think we are on the right track with this idea.
Dustin: To recap what Becky was saying is that nodes would not initially be punished with a 5% NAS reduction however, the stability index would be immediately increased. If a node is still offline after 10 polling cycles, it would be penalized with the locking of 5% of the collateral.
Becky: Yes, that is correct and what the other meeting concluded as the current solution. We can spend some time talking about the other proposals.
Dustin: So, most of the proposals can be broken down into two ideas
- Modify the penalty value since 5% may be too high
- Utilize the stability index to create a dynamic penalty value.
With that in mind, what is the position of others here today?
Sili: I think tracking node’s stability index can be described as now. If a node misses a cycle, then their stability index should be decreased but not incur a NAS penalty initially. I think that 10 hours is enough time for any node to react to a situation of a down node. This should allow for enough time for engineers to for example wake up and see a node is down. I do agree that the 10 hours timeframe is sufficient.
As far as the penalty value of 5%, I am unsure of. For example, if my stability index is 1 but I missed 8 cycles, my stability index goes down, am I looking at a 5% NAS slash?
Dustin: I believe that is what needs to be discussed. What should the penalty be once we exceed a certain threshold. In my opinion, the 5% is a bit much but I do agree with the 10 hour leadway time to give nodes time to fix the problem. Obviously, their stability index will drop during that time but that is recoverable. But the 5% penalty might be a bit high.
This is where I think the balance needs to come from to create a system that is not penalizing a node at such a high level based on infrastructure issues of a data center or if a node’s software has not been updated within a certain amount of time. We also need to discuss what is expected of a node such as update timing. Do all nodes need to be updated for example within 24 hours and if the node is not updated, what is the result. Due to a missed node update, the stability index of the node falls, possible NAS deduction, etc. I think issues like this need to be further explored to come up with expectations and fair rules.
Sili: As you mentioned, there may be unforeseen issues that come up with nodes. I think there needs to be a way for nodes to unregister as a node but still keep their votes. For example, if a node cannot be fixed within a couple of hours, the node should be able to unregister so they can take care of the issues and then come back online. This way, we know the node is not intentionally damaging the stability of the network and it takes some pressure off the node operator so they are not panicking when they exceed the 10 hour threshold.
Dustin: I agree with you on that. What do others think about the penalty amount?
Hitters: Right now, it’s about $270USD. Even at this number, it’s quite low. We may adjust the penalty and score a bit based on the issue. Regarding the time cycle of 10 hours, if you cannot get the problem fixed, the penalty of 5% will be charged to the node. But if the problem is fixed within the 10 cycles, there would not be any penalty fee and I think that is a fair solution.
Mark: And so if it’s longer than 10 hours, then you will have a penalty fee? Let’s say if you stay offline for a couple of days, what is the penalty?
Becky: If the node is paused within the 10 hour window from your control panel, you would not be penalized.
Mark: Ok, great so let’s say I receive a NAS penalty and my node is offline, do the penalties keep stacking up for the duration of being offline?
Dustin: No, they would not keep accumulating. Once you meet the requirements of the medium penalty, you would only receive the one deduction of 5% NAS.
I do like the 10 hour delay proposal for node penalties. This solves a lot of issues.
The only thing I see in the future with this proposed setup is in the future when the market increases, a 5% penalty may become too large of a penalty. I would like to hear the thoughts of others about this?
Sili: Yes, I agree that the 5% may be too much in the future.
I do have one additional question about the stability index. Let’s say I have a 1.0 stability index at the beginning of the 10 hour period. By the end of the 10 hour period, what would be my stability index? What kind of penalty am I looking at?
Becky: After the 10 hour period, you can start to increase your stability index with a 0.01 level per cycle.
Dustin: I believe it will drop well below the 0.5 level and from what I noticed during the testnet cycle, it would take approximately 3 days for the stability index to increase to a level where you would become an active consensus node once again.
So, this is another part of the penalty. Even if your node is back up within the 10 hour timeframe, your stability index will have to recover to become an active node once again.
Mark: I agree that part of the penalty is fair.
Dustin: So we will enact a 10 cycle system where nodes are not penalized in NAS but the stability index is decreased. Is everyone happy with that as a permanent solution or just until the community can develop something better?
Mark: I’m happy with this at this moment. In the future, we can further review this system. I do think that we may have to adjust the 5% NAS deduction in the future but I think the proposed solution is good for the longer term and see how it works out.
Sili: I think we are happy with the stability index penalty and as for the 5%, that may still be up for discussion. It may become a lot for a penalty but for now we are good with that.
Dustin: Excellent. I too agree that it’s a good solution and easy to implement. Does anyone else have any questions or concerns they would like to discuss here?
Sili: I think we could do with a table to showcase the stability index to make it clearer since there are questions in the community about this.
Dustin: Yes, that’s a good point. We need better charts showing the outcome of missing or mining blocks.
Becky: It looks like after two meetings, we have a solution for the penalty mechanism.
Hitters: I think after these two meetings, it’s clear that we made a conclusion for now. In the future, the NAS foundation will provide 2-3 additional options for the penalty mechanism. It’s really important to hear from the node operators and the community so we can continue to make improvements.
I also remember that Mark mentioned the token price and I would like to discuss this. Right now, we are actively looking for good business models for the entire blockchain industry. I think we can look at other public blockchains such as Ethereum, EOS and Polkadot for some direction to restructure the core of Nebulas. As we proceed, we will keep everyone updated regarding this. Does anyone have any suggestions?
Mark: I think a lot of this is market driven as well. During this market, a lot of people lose interest. Once there is more interest, the price will start going up along with more interest. With the newcomers, we may see some new ideas from these new members which could lead to new opportunities. It’s something we have to weather at the moment.
Dustin: Yes, I agree with Mark on this. As of now, the market is mostly speculative and once the price increases, more people will hop into blockchain and we will see another explosion of ideas and creativity in the ecosystem. Hopefully one of these ideas will be sparked on the Nebulas blockchain especially since we have some good things going for us such as decentralization and node operators have the potential of making a good profit. Overall, I’m hopeful for the future but for the current moment, it’s difficult to see what the proper direction is to take. For example, we just saw MKR have some issues on the Ethereum blockchain showing that the ecosystem takes more time to develop than we realize.
Sili: No matter what policy we decide to go, it’s o.k. to be complex as long as all the information presented to the community has to be really clear and simple. They may not have the technical background to understand consensus mechanism and its penalties. Some may not understand the risk involved in operating a node due to a lack of understanding.
Dustin: That’s a great point. We don’t need people to read the PoD whitepaper to understand how the system works and right now, that is what we are asking of them. We need a simplification of the system for users.
Hitters: Yes, I totally agree with that and maybe after PoD launches, we can have regular community meetings. As I mentioned before, I want to hear more from you guys and the community. Even at this low time, there is a lot of information and progress for the industry that we need to learn. It reminds me of 2014 when the industry was quite small but things still happened such as NEO/Antshares. In my point of view, this low time in the industry is a good time to look for opportunity in blockchain projects and to have a strong fundamental infrastructure.
We can take this time to learn from the community with bi-weekly meetings and we can learn from one-another.
