Alors, @Somnia_Network va-t-il frapper ce mur ? La plupart des gens s'excitent lorsque une blockchain revendique des vitesses rapides. Mais ce à quoi ils ne pensent pas, c'est ce qui se passe lorsque le nombre de validateurs augmente et que l'utilisation s'intensifie. Dans presque toutes les chaînes à haute performance, la référence originale, TPS, latence, finalité des blocs est généralement testée avec un petit ensemble de validateurs étroitement coordonné. Tout est léger, propre, optimisé. (1/4)

Mais une fois que le nombre de validateurs augmente, la surcharge de coordination augmente. Et @Somnia_Network veut avoir 100 validateurs avant le TGE... Plus de nœuds = plus de rumeurs = plus de latence. Le consensus prend plus de temps. Les blocs prennent un peu plus de temps à se propager et à se finaliser. Et les chaînes qui se vantent de "10 000 TPS" peuvent ralentir à 1 000 ou moins dans des conditions réelles. (2/4)

Alors, est-ce que @Somnia_Network va atteindre ce mur ? Somnia est conçu pour le jeu et les interactions à fort débit. Cela signifie qu'il a besoin de temps de bloc rapides et d'un TPS élevé sous charge, pas seulement dans des environnements de test. Mais à mesure qu'il se développe et attire plus de validateurs (et finit par se décentraliser), il y a un compromis à surveiller : + Plus de validateurs améliorent la sécurité et la résistance à la censure. + Mais ils peuvent également réduire le débit et augmenter la variabilité du temps de bloc. (3/4)

La question clé : @Somnia_Network peut-il optimiser pour les deux ? Si Somnia ou HAS ont déjà adopté le regroupement adaptatif des validateurs, l'exécution parallèle (comme ce que explore Aptos ou Sei), ou des preuves basées sur ZK pour le regroupement, cela pourrait maintenir la performance tout en se décentralisant ?? Ou est-ce que le consensus multistream résout simplement tout cela ?! Mais si cela ajoute juste plus de validateurs sans optimisations au niveau du protocole, la performance pourrait se dégrader. La quantité peut diminuer la qualité, à moins que l'architecture ne prévoie cela, et en utilisant ce multistream. Seul le validateur propriétaire ajoute des blocs à sa chaîne de données, et il n'y a pas de mécanismes de sécurité en place pour éviter qu'il ne fork sa chaîne de données ou ne propose des blocs invalides. En d'autres termes, les chaînes de données n'ont aucun mécanisme de consensus. Les blockchains rapides ont l'air géniales au lancement. Mais rester rapide avec des centaines ou des milliers de validateurs est le véritable défi. (4/4)