@nikitafuchs.chain yes, now it is the time for poking holes in the idea, so thanks for trying that.
What you’re describing though seems orthogonal to Hyperchains. If you’re malicious and try flooding the network with malicious nodes, you can do all sorts of nasty things. You can not propagate blocks to other participants, you can DDoS participants and etc.
What Hyperchains actually bring to the table is that you can still collect commitments on the parent chain, decide who are valid according your own source of truth - your local blockchain - and determine who the next leader shall be. If you’re under an Eclipse attack - you will see a lot of invalid commitments - and continue in a fork of your own. This is not a problem related to Hyperchains but they still provide you with some bells and whistles - if you see a lot of invalid commitments, you might as well be poorly connected. By no means the Hyperchain can provide more security than the parent chain but this is fine.
I have a question. Can Hyperchain be use-case specific?. What if we would like to have some features as inherent property of the blockchain.
Like apart from banking features or Oracles and state channels.
We would like to have Decentralize Identity document feature.
Its just a fashionable term to manage a set of JSON data that contains user information like a registry and the ID’s would follow a different specification unlike to public key .
I would like suggestion on how we would implement something like this in the mainnet for our MVP and suggestion on how to move to Hyperchain when its ready.
Hyperchains actually can indeed be more dynamic and could possibly follow other protocols, for example you could have a hyperchain with completely different primitives - digital identity if you’d like. Hyperchains are agnostic to those. This is a bit off topic, though. If you want to get into further details, you can start another thread.