The proposal posted entails many non-factual claims, and so warrants a response. And frankly, I would expect better from some of the signators on this proposal.
I also will not engage in extended debate around this. This will more or less be my one-time reply, and it should be taking as such.
Phychain and lankou wanted to co-sign this. If anyone else wants to put their name on as support, lmk and I will edit to add.
A significant point of order:
There is no place for formal proposals governing the shielded expedition. The document from these testnet-validators must therefore be seen as informal input, not a “proposal”, and not be given more weight than any other input.
Addressing unfactual claims in this proposal:
- “Argument 3”: The jailing bug was very real and confirmed by team. It was not for the reasons speculated by the “proposal”-authors, and is well attested as a genuine bug which affected both post-genesis and genesis validators significantly (you can ask amadison if you don’t believe me). As the “proposal”-authors state, it was fixed by updated code applies at hardfork. This in itself proves it was a tangible bug.
- “Argument 4”: “There is no evidence in the post-genesis validators’ chat history of major complaints or discussions regarding a lack or delay of information.” This is an outright lie, and there is plenty of evidence of complaints of the same. We have been complaining about this persistently before Gavin took over comms. Further, the particular event where chain was halted, we were told there would not be any restart for at least two hours (remember, this was after days of being on-edge waiting for a restart) and then suddenly everyone (shielded-100) spun up network within half an hour from coordination in the dedicated channel the rest of us don’t have access too. This event specifically lead to a number of validators getting jailed and also specifically lead to gavin taking over communications and zen being included in se-100 channel to prevent this from happening again. The allegations made here are put in bad faith and have no basis in what actually happened.
- “Argument 5”: There is some merit to some of the assertions made here, but they are not key to the discussion at hand. Some aspects are being omitted, such as the initial naan distribution being so skewed that genesis validators are for all practical purposes guaranteed a place in the active set, while everyone else (crew and pilots alike) would have to fight over the remaining 150 spaces. While I agree this has not been a big problem practically during most of the expedition, even one or two epochs where one would be below threshold, would severely limit the possibility to be included in the award-winning categories. Therefore, this is not a minor issue given 95 and 99 percent thresholds.
- A few other items could be mentioned, namely that there were some real issues along the testnet that required restarts, bad performance of the client, stuck blocks in validator etc, but these are not key either.
- One item that is key for a minor group is the bug around change-consensus-key which led to a situation of jail and inability to unjail before the convert-key feature was included in CLI.
- Regarding the argument that if one got jailed, one would automatically not meet the strictest criteria, this is also a disingenuous argument: There are 91 epochs in the shielded expedition testnet (0-90). For a post genesis validator that’s 89 epochs total where they could be part of the active set. The unjail mechanism works in such a way that if you go to jail, you’ll be in jail for a minimum of 2 epochs given that the mechanism works as intended and you unjail appropriately. Which as we know it did not for this testnet. But for the sake of the argument, yes that means that if one gets jailed for any reason, then one would not meet the 99% criterion. However, to meet the 95% criterion, one could have as little as 86.5 epochs in active set for genesis (two jailing periods possible), and 84.6 out of 89 epochs for post-genesis (also two jailing periods possible of two epochs each). In this way, it is simply not true that if one got jailed on the one time and the unjail-mechanism worked, then one would automatically fail both these reward-categories.
Let me also briefly address the repeated claim about “when counting correctly”, as that refer to my calculations that you all are using to draw inferences from:
- There is no “correct” way to count this. My main concern has been whether team has mapped all validator-TMs correctly, and Fraccaman states they have. This surprised me but will have to take that at face value.
- As for the calculations themselves, mine are very simply based on recorded signatures in the Namadexer, divided by total blocks (subtracting first two blocks for post-genesis, and doing some filtering logic to make sure noone is credited for any double-signs or such). I am aware (as per Daniel-keplr’s well-made comments on uptime-counting for instance) that there are probably much better ways to do so, and I can’t say if my way is better than team’s, simply because we have so little information.
With regards to the inferences drawn from these assertions, the following logical fallacy need to be addressed:
- That some validators managed to avoid being jailed etc, does not necessarily mean everyone else could have done the same (it also does not mean the opposite). This is self-evident and will not be argued further. In other words, validators could have real problems that you guys did not experience, and it does not necessarily have to be because you are better or smarter.
- Rules must be upkept regardless of what happens during testnet. This is also pretty self-evident. I am for upkeep of rules, but if circumstances change, it can (but does not have to) warrant changes in terms of competition and rewards structure.
As for some of the inferences made in the document, I want to just briefly remind the authors that terms and conditions of the Shielded Expedition gives organizing team very wide powers in what they can change. Just wanted to also get that in here, though I do believe this power should be used as sparsely as possible.