neo VS polkadot

Neo (3400 GitHub Stars) https://github.com/neo-project/neo

Some discussion that covers many of the arguments on both sides here: https://github.com/neo-project/neo/issues/2118

Take a look at something like https://github.com/neo-project/neo or https://github.com/Felandil/tangle-.net to see how much work is really required just to get something basic up and running.

Yes, this was a topic of considerable debate during N3's development. The degree to which one considers it a serious issue really depends on what one sees as the key features of governance--stability vs. democratic expression, etc. Of course, the basic fact of a node falling out of the top 21 isn't weird; the question is more around how easy it should be to get back in.

It's good discuss the voting mechanism and other aspects of NEO. Have you seen the comments on GitHub? A lot of people and devs (also people ^_^) are there, for example: https://github.com/neo-project/neo/issues/2598

One, there has been quite a bit of discussion over the past year about the design of the new governance system, and its potential flaws with respect to promoting node turnover--e.g. here, but also at various times in this sub (sidebar, you'll see that your "votes are reset" idea was proposed in that thread, say). As an oversimplified TL;DR, I think many--myself included--would agree with you that the system tends to promote the status quo. Where things get muddy is whether that's a feature or a bug. For reasons of both regulatory compliance and stability, the Neo team has intentionally designed a system where turnover, while possible, isn't specifically incentivized; that is, in their view it should happen because there's a strong, governance-related reason for it, not because of financial incentives.

The governance model has been designed to incentivise stability while still allowing flexibility. However, the issue you raise is already being discussed on GitHub here: https://github.com/neo-project/neo/issues/2598

Polkadot (6400 GitHub Stars) https://github.com/paritytech/polkadot

I don't think asynchronous backing has any direct effect on the number of parachains, no (I mean, there likely is an effect, but it's not the goal and my understanding is that any effect on that would be minimal, although I'm not involved in the deep engineering here). It increases throughput, correct, by decreasing the time between blocks by not needing to do a "roundtrip" to the relay chain to build new blocks. See https://github.com/paritytech/polkadot/issues/3779 for an overview.

"The 27 waiting day is unavoidable and a very important security measure to protect against certain attacks and vulnerabilities of PoS. I totally understand that it is annoying, but arguably it is for the benefit+security of the overall network, which includes you as well at the end of the day as DOT-holder." - from this GitHub discussion.

Ref: Kianenigma @ https://github.com/paritytech/polkadot/issues/2418

Polkadot 0.9.37 has been released with MEDIUM upgrade priority. https://github.com/paritytech/polkadot/releases/tag/v0.9.37

Specifically, it was this PR that changed it: https://github.com/paritytech/polkadot/pull/6230

Actually it looks like you can! It's just not recommended. This is from the official documentation: "Starting with runtime version v23 natively included in the client version 0.8.23, payouts can go to any custom address. If you'd like to redirect payments to an account that is neither the controller nor the stash account, set one up. Note that setting an exchange address as the recipient of the staking rewards is extremely unsafe.*

A particular validator sent out a LOT of dispute reports (i.e., saying that other validators did something incorrectly) last night (for reasons unknown). It looks like other nodes "choked" reading all of these disputes, and one subsystem died, stalling nodes but NOT killing the process. It's still being investigated, but you can look at the issue on Github to see it being discussed here: https://github.com/paritytech/polkadot/issues/6412