$DUSK He puesto a prueba muchos nodos en la práctica; lo que más desgasta no es que el volumen de transacciones sea brutal, sino el desastre de radiodifusión descontrolada en la capa P2P. Las cadenas antiguas, cuando se mueven un poco, se traban: el problema está en ese viejo y oxidado mecanismo Gossip. Es un envío ciego a todo el grupo; cuando la red se agita un poco, el efecto avalancha de paquetes perdidos repetidos deja la memoria del servidor inutilizable de inmediato.
Más tarde, al revisar el nivel base de @Dusk , descubrí que en su arquitectura Kadcast hace unas operaciones bastante ingeniosas. Este proyecto no siguió el camino antiguo de inundar todo. En su lugar, usa un algoritmo XOR para trazar una red de distribución dirigida. Cada dispositivo solo necesita ocuparse de empujar datos dentro de su propio rango pequeño; así, desde la fuente se evita meter un envío caótico en rutas fijas. Incluso si el volumen de transacciones se dispara de golpe, los datos residuales en el borde quedan contenidos.
Pero, por los tropiezos que yo mismo pisé, aunque el plano en papel sea increíble, al meterlo en un centro de datos real hay que aplicarle un descuento. Si se mete la topología XOR en la capa de transporte, en apariencia hasta puedes montar un nodo en un ordenador “normal”; pero el problema es que cada día hay un montón de gente que desconecta, sale y apaga el equipo. Una vez que un grupo masivo se queda atrás, las tablas de enrutamiento no reaccionan a tiempo. Si te toca una ruptura de red de verdad, reparar estas rutas precisas es mucho más difícil que la inundación. Intentar investigar un problema de pérdida de paquetes puede volver loco a cualquiera. $BTC
Para comprobar si el “esqueleto” de una cadena es fuerte, no mires solo las pruebas infladas de TPS; hay que ver si la arquitectura de base aguanta cuando todo colapsa en el peor de los casos. Al bloquear los datos con distancias matemáticas y evitar que vuelen al azar, es un enfoque que habla de eficacia. Pero si esto puede mantenerse a flote en un escenario de práctica extremadamente caótico… creo que aún hay que ver si es capaz de soportar durante un tiempo las embestidas de un flujo masivo de verdad. #dusk $ETH
Más tarde, al revisar el nivel base de @Dusk , descubrí que en su arquitectura Kadcast hace unas operaciones bastante ingeniosas. Este proyecto no siguió el camino antiguo de inundar todo. En su lugar, usa un algoritmo XOR para trazar una red de distribución dirigida. Cada dispositivo solo necesita ocuparse de empujar datos dentro de su propio rango pequeño; así, desde la fuente se evita meter un envío caótico en rutas fijas. Incluso si el volumen de transacciones se dispara de golpe, los datos residuales en el borde quedan contenidos.
Pero, por los tropiezos que yo mismo pisé, aunque el plano en papel sea increíble, al meterlo en un centro de datos real hay que aplicarle un descuento. Si se mete la topología XOR en la capa de transporte, en apariencia hasta puedes montar un nodo en un ordenador “normal”; pero el problema es que cada día hay un montón de gente que desconecta, sale y apaga el equipo. Una vez que un grupo masivo se queda atrás, las tablas de enrutamiento no reaccionan a tiempo. Si te toca una ruptura de red de verdad, reparar estas rutas precisas es mucho más difícil que la inundación. Intentar investigar un problema de pérdida de paquetes puede volver loco a cualquiera. $BTC
Para comprobar si el “esqueleto” de una cadena es fuerte, no mires solo las pruebas infladas de TPS; hay que ver si la arquitectura de base aguanta cuando todo colapsa en el peor de los casos. Al bloquear los datos con distancias matemáticas y evitar que vuelen al azar, es un enfoque que habla de eficacia. Pero si esto puede mantenerse a flote en un escenario de práctica extremadamente caótico… creo que aún hay que ver si es capaz de soportar durante un tiempo las embestidas de un flujo masivo de verdad. #dusk $ETH