#dusk $DUSK @Dusk
Lo que llamó mi atención no fue la parte de conocimiento cero de Dusk que suele acaparar la mayor atención, sino un detalle más pequeño sobre cómo un bloque realmente se vuelve final.
Quería comprobar cómo Succinct Attestation, el protocolo de consenso de prueba de participación sin permisos basado en comités de DuskDS, confirma una transacción, ya que en este espacio se habla de liquidación instantánea de forma algo laxa.
Cada ronda pasa por tres pasos: un proponente propone y difunde un bloque candidato, un comité lo valida y, después, un segundo comité ratifica esa validación y finaliza el bloque. Solo después de que ambos comités estén de acuerdo, el bloque avanza.
Lo interesante es que @Dusk no trata la finalización como un único evento binario. Un bloque se acepta una vez que supera los tres pasos; se confirma una vez que los bloques posteriores se construyen sobre él; se vuelve estable cuando está lo suficientemente enterrado y, finalmente, final cuando es determinista y criptográficamente garantizado, lo que significa que no puede revertirse.
Para una liquidación regulada, esa distinción por etapas importa más que la velocidad bruta. Un custodio no solo necesita que una transacción sea rápida; necesita un punto definido en el que lo irreversible sea demostrable, no asumido.
Lo que me gustaría que se aclarara es el comportamiento bajo carga sostenida. Que dos comités distintos estén de acuerdo agrega un paso de coordinación que las cadenas con un único proponente se saltan. A medida que crecen el conjunto de proponentes y la distribución de participación, ¿la ratificación se mantiene rápida o la coordinación entre comités se convierte en el cuello de botella?
Los documentos describen las fases y la división de recompensas: 70% para el proponente y 5%/5% para los comités de validación y ratificación. Lo que no queda claro es el límite de rendimiento bajo congestión real de la red, solo se prueba el comportamiento en testnet.
¿Alguien ha visto datos de selección de comités o de tiempos de finalización de Dusk bajo una carga real sostenida de transacciones, en lugar de números de red inactiva?
$DUSK #Dusk
Lo que llamó mi atención no fue la parte de conocimiento cero de Dusk que suele acaparar la mayor atención, sino un detalle más pequeño sobre cómo un bloque realmente se vuelve final.
Quería comprobar cómo Succinct Attestation, el protocolo de consenso de prueba de participación sin permisos basado en comités de DuskDS, confirma una transacción, ya que en este espacio se habla de liquidación instantánea de forma algo laxa.
Cada ronda pasa por tres pasos: un proponente propone y difunde un bloque candidato, un comité lo valida y, después, un segundo comité ratifica esa validación y finaliza el bloque. Solo después de que ambos comités estén de acuerdo, el bloque avanza.
Lo interesante es que @Dusk no trata la finalización como un único evento binario. Un bloque se acepta una vez que supera los tres pasos; se confirma una vez que los bloques posteriores se construyen sobre él; se vuelve estable cuando está lo suficientemente enterrado y, finalmente, final cuando es determinista y criptográficamente garantizado, lo que significa que no puede revertirse.
Para una liquidación regulada, esa distinción por etapas importa más que la velocidad bruta. Un custodio no solo necesita que una transacción sea rápida; necesita un punto definido en el que lo irreversible sea demostrable, no asumido.
Lo que me gustaría que se aclarara es el comportamiento bajo carga sostenida. Que dos comités distintos estén de acuerdo agrega un paso de coordinación que las cadenas con un único proponente se saltan. A medida que crecen el conjunto de proponentes y la distribución de participación, ¿la ratificación se mantiene rápida o la coordinación entre comités se convierte en el cuello de botella?
Los documentos describen las fases y la división de recompensas: 70% para el proponente y 5%/5% para los comités de validación y ratificación. Lo que no queda claro es el límite de rendimiento bajo congestión real de la red, solo se prueba el comportamiento en testnet.
¿Alguien ha visto datos de selección de comités o de tiempos de finalización de Dusk bajo una carga real sostenida de transacciones, en lugar de números de red inactiva?
$DUSK #Dusk