El momento más incómodo en una cadena de liquidación de valores no es necesariamente que entre un hacker, sino que nadie cometa una maldad evidente y, aun así, el libro mayor no logra pasar a la siguiente página durante mucho tiempo. Se desconectan nodos, ocurre una partición de red, no se reúne el quórum en la comisión: el dinero no se pierde, pero todos solo pueden esperar. En una cadena pública común, esto se llama congestión; en el mercado financiero, podría convertirse directamente en un incidente de entrega y recepción.
Vuelvo a leer el “Emergency Mode” del libro blanco @Dusk y veo que no se finge que esta situación no ocurrirá. En cada ronda, Succinct Attestation como máximo ejecuta 50 iteraciones; cuando fallan 16 iteraciones consecutivas, el protocolo entra en modo de emergencia. Los pasos que en el flujo normal exceden el tiempo límite se desactivan; NoCandidate y NoQuorum tampoco vuelven a usarse como resultado para avanzar. Las iteraciones ya iniciadas continúan esperando hasta que el bloque candidato y, mediante dos fases de validación y aprobación, se alcancen de verdad los votos legales.
El sentido de este diseño es muy directo: en condiciones normales, el consenso puede saltar a la siguiente tanda de participantes por causa de los timeouts, pero en el caso extremo no se puede depender de que “nadie llega a tiempo” para saltarse el problema. El sistema prefiere dejar en paralelo varias iteraciones abiertas, aun así, esperar a que exista un bloque que la comisión pueda confirmar, para aumentar la probabilidad de que el libro mayor siga avanzando.
Pero el costo también está escrito en el libro blanco. Las iteraciones en paralelo pueden hacer que en una misma ronda aparezcan varios bloques candidatos que ya obtuvieron consenso, con lo cual el riesgo de bifurcación aumenta. El protocolo solo puede resolverlo escogiendo el candidato con el número de iteración más bajo. Si al final todavía no se logra recuperar, la mayoría de los derechos de pignoración también puede solicitar conjuntamente un bloque de emergencia vacío que no incluya transacciones; entonces, los nodos de Dusk generan una nueva semilla para que la red pase esta ronda.
No lo voy a interpretar como un “nunca se detiene”. Es más bien un manual de recuperación ante desastres: reconoce que el consenso puede perder el ritmo y, al mismo tiempo, define quién puede impulsar la recuperación, y qué se puede sacrificar durante la recuperación. En el futuro, al evaluar la capacidad de liquidación financiera de $DUSK , me importará más el número de veces que realmente se activa el modo de emergencia, su duración, la cantidad de bifurcaciones y la solicitud de bloques vacíos, que solo mirar cuánto tarda en producir bloques en condiciones normales.
La infraestructura de nivel institucional no es aquella que nunca falla, sino aquella que, cuando ocurre un fallo, tiene las reglas de manejo escritas con anticipación y el costo puede ser visto por todos.
#dusk
Vuelvo a leer el “Emergency Mode” del libro blanco @Dusk y veo que no se finge que esta situación no ocurrirá. En cada ronda, Succinct Attestation como máximo ejecuta 50 iteraciones; cuando fallan 16 iteraciones consecutivas, el protocolo entra en modo de emergencia. Los pasos que en el flujo normal exceden el tiempo límite se desactivan; NoCandidate y NoQuorum tampoco vuelven a usarse como resultado para avanzar. Las iteraciones ya iniciadas continúan esperando hasta que el bloque candidato y, mediante dos fases de validación y aprobación, se alcancen de verdad los votos legales.
El sentido de este diseño es muy directo: en condiciones normales, el consenso puede saltar a la siguiente tanda de participantes por causa de los timeouts, pero en el caso extremo no se puede depender de que “nadie llega a tiempo” para saltarse el problema. El sistema prefiere dejar en paralelo varias iteraciones abiertas, aun así, esperar a que exista un bloque que la comisión pueda confirmar, para aumentar la probabilidad de que el libro mayor siga avanzando.
Pero el costo también está escrito en el libro blanco. Las iteraciones en paralelo pueden hacer que en una misma ronda aparezcan varios bloques candidatos que ya obtuvieron consenso, con lo cual el riesgo de bifurcación aumenta. El protocolo solo puede resolverlo escogiendo el candidato con el número de iteración más bajo. Si al final todavía no se logra recuperar, la mayoría de los derechos de pignoración también puede solicitar conjuntamente un bloque de emergencia vacío que no incluya transacciones; entonces, los nodos de Dusk generan una nueva semilla para que la red pase esta ronda.
No lo voy a interpretar como un “nunca se detiene”. Es más bien un manual de recuperación ante desastres: reconoce que el consenso puede perder el ritmo y, al mismo tiempo, define quién puede impulsar la recuperación, y qué se puede sacrificar durante la recuperación. En el futuro, al evaluar la capacidad de liquidación financiera de $DUSK , me importará más el número de veces que realmente se activa el modo de emergencia, su duración, la cantidad de bifurcaciones y la solicitud de bloques vacíos, que solo mirar cuánto tarda en producir bloques en condiciones normales.
La infraestructura de nivel institucional no es aquella que nunca falla, sino aquella que, cuando ocurre un fallo, tiene las reglas de manejo escritas con anticipación y el costo puede ser visto por todos.
#dusk
