Hablando de @Dusk , recientemente hubo un aumento repentino de discusiones en la plaza. Me di cuenta de que mucha gente mira “verificación en cadena de 2,8 milisegundos” y piensa que el asunto está resuelto; sinceramente, un poco se han dejado llevar.
Que sea rápido en la cadena no significa que sea rápido en general. Son dos conceptos. Las pruebas PLONK, efectivamente, son ligeras en la verificación en cadena; según datos oficiales, ronda los 6,13 milisegundos. Pero el problema es que ese “rápido” se basa en el costo de cómputo de generar la prueba (Proving) que alguien más asume por ti. Generar una prueba PLONK requiere 5,46 segundos. Lo interesante es que una prueba única del circuito de identidad de Citadel tarda aproximadamente 16 segundos y tiene unas 34.000 restricciones: el sobrecoste computacional está en el orden de decenas de miles respecto a la verificación en cadena. ¿Quién hace de Prover? ¿Por qué los nodos te ayudarían gratis a ejecutar esto? La transferencia de costos “ligero en cadena, pesado fuera de la cadena” es, en realidad, el costo verdadero.
Hablemos también de cumplimiento. El esquema de identidad de Citadel con divulgación selectiva, en el diseño, ciertamente es elegante. Pero tengo una duda: el “cero conocimientos” del KYC con conocimiento cero, ¿cero conocimiento para quién? El usuario puede no revelar la privacidad a la plataforma, pero la certificación inicial depende de terceros externos a la cadena. Hay tensión entre este flujo y el núcleo desintermediado (descentralizado) de confianza: en la cadena se puede verificar “que superaste la certificación”, pero no se puede verificar “que la entidad certificadora no hizo trampa”.
Lo que más me preocupa es la vulnerabilidad de seguridad recientemente expuesta en PLONK. El verificador nunca verifica las cuatro promesas polinomiales proporcionadas por el probador; un probador malicioso puede falsificar la prueba y acuñar DUSK de la nada. Aunque el oficial ya lo corrigió, esto demuestra una cosa: por más auditorías de código que haya, los fallos igual terminan apareciendo.
Entonces, ¿cuál es la conclusión? El costo real de DUSK no está en el tamaño de los datos en cadena, sino en esto: cuántos nodos están dispuestos a soportar la potencia de Proving y cuántos reguladores están dispuestos a integrarse con su capa de identidad fuera de la cadena. Esa es la clave para evaluarlo. ¿Qué opinan, gente?
#dusk $DUSK
Que sea rápido en la cadena no significa que sea rápido en general. Son dos conceptos. Las pruebas PLONK, efectivamente, son ligeras en la verificación en cadena; según datos oficiales, ronda los 6,13 milisegundos. Pero el problema es que ese “rápido” se basa en el costo de cómputo de generar la prueba (Proving) que alguien más asume por ti. Generar una prueba PLONK requiere 5,46 segundos. Lo interesante es que una prueba única del circuito de identidad de Citadel tarda aproximadamente 16 segundos y tiene unas 34.000 restricciones: el sobrecoste computacional está en el orden de decenas de miles respecto a la verificación en cadena. ¿Quién hace de Prover? ¿Por qué los nodos te ayudarían gratis a ejecutar esto? La transferencia de costos “ligero en cadena, pesado fuera de la cadena” es, en realidad, el costo verdadero.
Hablemos también de cumplimiento. El esquema de identidad de Citadel con divulgación selectiva, en el diseño, ciertamente es elegante. Pero tengo una duda: el “cero conocimientos” del KYC con conocimiento cero, ¿cero conocimiento para quién? El usuario puede no revelar la privacidad a la plataforma, pero la certificación inicial depende de terceros externos a la cadena. Hay tensión entre este flujo y el núcleo desintermediado (descentralizado) de confianza: en la cadena se puede verificar “que superaste la certificación”, pero no se puede verificar “que la entidad certificadora no hizo trampa”.
Lo que más me preocupa es la vulnerabilidad de seguridad recientemente expuesta en PLONK. El verificador nunca verifica las cuatro promesas polinomiales proporcionadas por el probador; un probador malicioso puede falsificar la prueba y acuñar DUSK de la nada. Aunque el oficial ya lo corrigió, esto demuestra una cosa: por más auditorías de código que haya, los fallos igual terminan apareciendo.
Entonces, ¿cuál es la conclusión? El costo real de DUSK no está en el tamaño de los datos en cadena, sino en esto: cuántos nodos están dispuestos a soportar la potencia de Proving y cuántos reguladores están dispuestos a integrarse con su capa de identidad fuera de la cadena. Esa es la clave para evaluarlo. ¿Qué opinan, gente?
#dusk $DUSK