Entonces, ¿@Somnia_Network chocará contra este muro? La mayoría de la gente se emociona cuando una cadena de bloques afirma velocidades rápidas. Pero en lo que no piensan es en lo que sucede cuando los validadores aumentan y el uso escala. En casi todas las cadenas de alto rendimiento, el punto de referencia original, el TPS, la latencia y la finalidad del bloque generalmente se prueban con un conjunto de validadores pequeño y estrechamente coordinado. Todo es esbelto, limpio, optimizado. (1/4)

Pero una vez que crece el número de validadores, aumenta la sobrecarga de coordinación. Y @Somnia_Network quiere tener 100 validadores antes de TGE... Más nodos = más chismes = más latencia. El consenso lleva más tiempo. Los bloques tardan un poco más en propagarse y finalizarse. Y las cadenas que se jactan de "10,000 TPS" pueden reducir a 1,000 o menos en condiciones del mundo real (2/4)

Entonces, ¿@Somnia_Network chocará contra este muro? Somnia está diseñado para juegos e interacciones de alto rendimiento Eso significa que necesita tiempos de bloque rápidos y un alto TPS bajo carga, no solo en entornos de prueba. Pero a medida que escala y atrae a más validadores (y eventualmente se descentraliza), hay una compensación que monitorear: + Más validadores mejoran la seguridad y la resistencia a la censura + Pero también pueden reducir el rendimiento y aumentar la variabilidad del tiempo de bloque (3/4)

La pregunta clave: ¿@Somnia_Network puede optimizar para ambos? Si Somnia o HAS ya han adoptado la agrupación en clústeres de validadores adaptativos, la ejecución paralela (como la que están explorando Aptos o Sei) o pruebas basadas en ZK para el procesamiento por lotes, ¿podría mantener el rendimiento a medida que se descentraliza? ¿O es que el consenso múltiple simplemente resuelve todo esto? Pero si solo agrega más validadores sin optimizaciones a nivel de protocolo, el rendimiento podría degradarse. La cantidad puede reducir la calidad, a menos que la arquitectura lo anticipe, y mediante el uso de este flujo múltiple Solo el validador propietario agrega bloques a su cadena de datos, y no existen mecanismos de seguridad para evitar que bifurquen su cadena de datos o propongan bloques no válidos. En otras palabras, las cadenas de datos no tienen ningún mecanismo de consenso. Las cadenas de bloques rápidas se ven muy bien en el lanzamiento. Pero mantenerse rápido con cientos o miles de validadores es el verdadero desafío. (4/4)