Corrí y probé nodos durante medio año, y ahora me he acostumbrado a empezar a “desnudar” la capa de propagación primero. Hace poco caí en un agujero: el ancho de banda del nodo se llenó al máximo y los correos de alerta llegaron en una pantalla entera. Al principio pensé que era por un volumen de transacciones demasiado fuerte; al revisar los registros entendí la causa: a nivel inferior, el valor predeterminado es un “bombardeo” de todo el mundo con tráfico indiscriminado. Con que el nodo se mueva un poco o tenga alguna inestabilidad, los mensajes repetidos se aprietan sin piedad, como si fuera un atasco.
Luego revisé el documento @Dusk y vi la parte de Kadcast; de hecho me quedé bastante tiempo. No usa ese tipo de difusión ciega. Aprovecha la topología de Kademlia: calcula la distancia XOR a partir del hash de identidad del nodo y clasifica el par en distintos buckets de enrutamiento. En la difusión, ya no se hace envío desordenado en masa; en su lugar, se envía de forma ordenada por capas según la distancia, y sincroniza toda la red convirtiéndola en un árbol de multidifusión estructurado. En mis pruebas locales, el pico de ancho de banda se redujo claramente; y después de varios saltos, resulta mucho más difícil que un actor externo deduzca al iniciador solo por características del tráfico. El whitepaper dice que ahorra 25%-50% de ancho de banda frente a un Gossip tradicional; yo lo tomo como referencia: con nodos que entran y salen con frecuencia, oscilaciones entre zonas y retrasos en la actualización de la tabla de enrutamiento, todo eso junto seguro reduce el ahorro real. Con BitVM3 como verificación de respaldo, no hay forma de que transacciones no conformes ni siquiera entren por la puerta. Esa idea comparte la lógica de bajo nivel con el esquema de “staking”: dejar las reglas soldadas en la criptografía.
Pero depender mucho de la topología lógica tiene un coste. Si aparece una partición entre países, o un nodo malicioso introduce datos sucios dentro de los buckets de enrutamiento, el gasto de direccionamiento al cambiar rutas alternativas puede comerse rápidamente la ventaja de baja latencia. Controlar el ancho de banda es realmente algo bueno: los usuarios comunes de staking no necesitan tirar de una línea dedicada y la barrera baja un escalón; pero la depuración es más compleja que en la difusión tradicional, así que hay que tenerlo en mente.
También pisé un pozo con el entre-cadenas. De la mainnet a BSC no es un “traslado” directo. Hay que enviar el DUSK nativo a la cuenta puente oficial; una vez que la mainnet valida y bloquea, según la dirección BSC especificada en el Memo, se genera un BEP20. La cantidad debe ser mayor que 1 DUSK. La tarifa es la comisión de la mainnet más la tarifa del puente de 1 DUSK; el tiempo aproximado es de una hora para llegar, y el monto real recibido es la cantidad enviada menos 1.
Kadcast usa una distancia matemática para mitigar el riesgo de redundancia y de rastreo del origen, pero en un entorno de red pública donde los nodos entran y salen, la velocidad de actualización de la tabla de enrutamiento y el grosor del pool alternativo—eso es lo que realmente hay que vigilar. Si sale bien, es una mejora pragmática; si no, es solo un decorado de papel. $DUSK #dusk $DUSK
Luego revisé el documento @Dusk y vi la parte de Kadcast; de hecho me quedé bastante tiempo. No usa ese tipo de difusión ciega. Aprovecha la topología de Kademlia: calcula la distancia XOR a partir del hash de identidad del nodo y clasifica el par en distintos buckets de enrutamiento. En la difusión, ya no se hace envío desordenado en masa; en su lugar, se envía de forma ordenada por capas según la distancia, y sincroniza toda la red convirtiéndola en un árbol de multidifusión estructurado. En mis pruebas locales, el pico de ancho de banda se redujo claramente; y después de varios saltos, resulta mucho más difícil que un actor externo deduzca al iniciador solo por características del tráfico. El whitepaper dice que ahorra 25%-50% de ancho de banda frente a un Gossip tradicional; yo lo tomo como referencia: con nodos que entran y salen con frecuencia, oscilaciones entre zonas y retrasos en la actualización de la tabla de enrutamiento, todo eso junto seguro reduce el ahorro real. Con BitVM3 como verificación de respaldo, no hay forma de que transacciones no conformes ni siquiera entren por la puerta. Esa idea comparte la lógica de bajo nivel con el esquema de “staking”: dejar las reglas soldadas en la criptografía.
Pero depender mucho de la topología lógica tiene un coste. Si aparece una partición entre países, o un nodo malicioso introduce datos sucios dentro de los buckets de enrutamiento, el gasto de direccionamiento al cambiar rutas alternativas puede comerse rápidamente la ventaja de baja latencia. Controlar el ancho de banda es realmente algo bueno: los usuarios comunes de staking no necesitan tirar de una línea dedicada y la barrera baja un escalón; pero la depuración es más compleja que en la difusión tradicional, así que hay que tenerlo en mente.
También pisé un pozo con el entre-cadenas. De la mainnet a BSC no es un “traslado” directo. Hay que enviar el DUSK nativo a la cuenta puente oficial; una vez que la mainnet valida y bloquea, según la dirección BSC especificada en el Memo, se genera un BEP20. La cantidad debe ser mayor que 1 DUSK. La tarifa es la comisión de la mainnet más la tarifa del puente de 1 DUSK; el tiempo aproximado es de una hora para llegar, y el monto real recibido es la cantidad enviada menos 1.
Kadcast usa una distancia matemática para mitigar el riesgo de redundancia y de rastreo del origen, pero en un entorno de red pública donde los nodos entran y salen, la velocidad de actualización de la tabla de enrutamiento y el grosor del pool alternativo—eso es lo que realmente hay que vigilar. Si sale bien, es una mejora pragmática; si no, es solo un decorado de papel. $DUSK #dusk $DUSK