#dusk $DUSK @Dusk Hoy estaba revisando mi pequeña posición de prueba de DUSK y me sorprendí haciéndome una suposición bastante básica: solía pensar que los árboles de Merkle y las pruebas de conocimiento cero estaban haciendo, más o menos, el mismo trabajo.
Al profundizar en @Dusk, eso cambió para mí.
Dusk-Merkle y PLONK no son intercambiables. Resuelven problemas distintos, y esa diferencia importa cuando intentas entender de dónde proviene realmente la privacidad.
Dusk-Merkle es un árbol Merkle disperso (sparse) personalizado y es agnóstico a la función hash. Se puede usar en diferentes partes de la red, incluyendo Stake, Transfer y Citadel.
La forma simple en la que ahora lo pienso:
Merkle = comprometerse con el estado.
PLONK = probar un cálculo.
Un árbol Merkle puede comprimir un estado estructurado en una raíz. Una apertura de Merkle puede entonces demostrar que un elemento particular pertenece a esa estructura comprometida sin exigir que el verificador procese todo el árbol.
PLONK va por otro lado. Permite que un probador demuestre que una afirmación o cálculo satisface un circuito sin revelar la información privada utilizada para producir esa prueba.
Esa separación en realidad me hizo entender la $DUSK arquitectura con más facilidad.
El árbol organiza y se compromete con el estado.
El circuito define qué debe cumplirse.
La prueba demuestra que se cumplieron las reglas.
Entonces el contrato puede determinar qué transición de estado sigue.
Pero aquí está la parte que me resulta más interesante.
La flexibilidad no es automáticamente seguridad.
Un diseño de Merkle agnóstico a la función hash todavía depende de elegir la función hash correcta e implementar las aperturas correctamente. Los circuitos reutilizables de PLONK tienen una compensación similar: reducen el trabajo duplicado, pero una suposición errónea potencialmente puede reutilizarse en múltiples aplicaciones.
Así que no solo estoy vigilando si DUSK usa ZK.
Estoy vigilando si cada componente criptográfico está haciendo exactamente el trabajo para el que fue diseñado.
#dusk $DUSK
@Dusk
$BTW
$TUT
$CYS
¿Qué es lo que más importa para la privacidad de Dusk?
Al profundizar en @Dusk, eso cambió para mí.
Dusk-Merkle y PLONK no son intercambiables. Resuelven problemas distintos, y esa diferencia importa cuando intentas entender de dónde proviene realmente la privacidad.
Dusk-Merkle es un árbol Merkle disperso (sparse) personalizado y es agnóstico a la función hash. Se puede usar en diferentes partes de la red, incluyendo Stake, Transfer y Citadel.
La forma simple en la que ahora lo pienso:
Merkle = comprometerse con el estado.
PLONK = probar un cálculo.
Un árbol Merkle puede comprimir un estado estructurado en una raíz. Una apertura de Merkle puede entonces demostrar que un elemento particular pertenece a esa estructura comprometida sin exigir que el verificador procese todo el árbol.
PLONK va por otro lado. Permite que un probador demuestre que una afirmación o cálculo satisface un circuito sin revelar la información privada utilizada para producir esa prueba.
Esa separación en realidad me hizo entender la $DUSK arquitectura con más facilidad.
El árbol organiza y se compromete con el estado.
El circuito define qué debe cumplirse.
La prueba demuestra que se cumplieron las reglas.
Entonces el contrato puede determinar qué transición de estado sigue.
Pero aquí está la parte que me resulta más interesante.
La flexibilidad no es automáticamente seguridad.
Un diseño de Merkle agnóstico a la función hash todavía depende de elegir la función hash correcta e implementar las aperturas correctamente. Los circuitos reutilizables de PLONK tienen una compensación similar: reducen el trabajo duplicado, pero una suposición errónea potencialmente puede reutilizarse en múltiples aplicaciones.
Así que no solo estoy vigilando si DUSK usa ZK.
Estoy vigilando si cada componente criptográfico está haciendo exactamente el trabajo para el que fue diseñado.
#dusk $DUSK
@Dusk
$BTW
$TUT
$CYS
¿Qué es lo que más importa para la privacidad de Dusk?
Merkle commits state
0%
PLONK proves rules
0%
Both have boundaries
0%
Which matters most?
0%
0 Voto(s) • Votación cerrada