#dusk $DUSK @Dusk
Una prueba de transacción confidencial de Dusk se sitúa aproximadamente en medio kilobyte. No importa si la computación subyacente es una simple transferencia o una verificación de liquidación multipartita con lógica de cumplimiento integrada. Mismo tamaño. Ese es el número principal, y es el tipo de dato que se repite sin que nadie pregunte qué está ocultando.
El sistema de pruebas que hay detrás, PLONK, es un zk-SNARK diseñado para pruebas de tamaño constante y un tiempo de verificación que crece de forma sublineal con la complejidad del circuito, ejecutándose sobre las curvas BLS12-381 y JubJub, con compromisos de Kate que mantienen esos compromisos de tamaño constante. La verdadera ventaja de diseño no es el tamaño de la prueba, sino la configuración (setup). Groth16 te da una prueba más pequeña, alrededor de 128 bytes, pero necesita una cadena de referencia específica para cada circuito (circuit-specific reference string), lo que limita su practicidad cuando despliegas muchos tipos diferentes de circuitos. La configuración de PLONK es reutilizable entre circuitos. Para una cadena que busca admitir muchas plantillas distintas de contratos confidenciales, ese intercambio es el más importante.
Aquí está la parte que no escala con tanta elegancia: el tiempo de generación de la prueba. El probador original de Plonk tiene una complejidad temporal que crece con el tamaño del circuito que se está probando. Los verificadores se mantienen ligeros, pero quien genera la prueba —la billetera, el nodo— no. A medida que los contratos XSC agregan más ramas de liquidación, comprobaciones de cumplimiento, lógica multipartita, el circuito crece y el costo de generar la prueba también. En algún punto, la economía empieza a favorecer infraestructuras de prueba dedicadas en lugar de la generación local, lo cual es un lugar extraño para acabar para una cadena centrada en la privacidad.
El diseño de comisiones eventualmente tiene que contemplar ese cambio: quien termine haciendo la computación pesada. ¿La arquitectura de Dusk seguirá descentralizada una vez que generar pruebas se vuelva lo suficientemente costoso como para externalizarlo?
Una prueba de transacción confidencial de Dusk se sitúa aproximadamente en medio kilobyte. No importa si la computación subyacente es una simple transferencia o una verificación de liquidación multipartita con lógica de cumplimiento integrada. Mismo tamaño. Ese es el número principal, y es el tipo de dato que se repite sin que nadie pregunte qué está ocultando.
El sistema de pruebas que hay detrás, PLONK, es un zk-SNARK diseñado para pruebas de tamaño constante y un tiempo de verificación que crece de forma sublineal con la complejidad del circuito, ejecutándose sobre las curvas BLS12-381 y JubJub, con compromisos de Kate que mantienen esos compromisos de tamaño constante. La verdadera ventaja de diseño no es el tamaño de la prueba, sino la configuración (setup). Groth16 te da una prueba más pequeña, alrededor de 128 bytes, pero necesita una cadena de referencia específica para cada circuito (circuit-specific reference string), lo que limita su practicidad cuando despliegas muchos tipos diferentes de circuitos. La configuración de PLONK es reutilizable entre circuitos. Para una cadena que busca admitir muchas plantillas distintas de contratos confidenciales, ese intercambio es el más importante.
Aquí está la parte que no escala con tanta elegancia: el tiempo de generación de la prueba. El probador original de Plonk tiene una complejidad temporal que crece con el tamaño del circuito que se está probando. Los verificadores se mantienen ligeros, pero quien genera la prueba —la billetera, el nodo— no. A medida que los contratos XSC agregan más ramas de liquidación, comprobaciones de cumplimiento, lógica multipartita, el circuito crece y el costo de generar la prueba también. En algún punto, la economía empieza a favorecer infraestructuras de prueba dedicadas en lugar de la generación local, lo cual es un lugar extraño para acabar para una cadena centrada en la privacidad.
El diseño de comisiones eventualmente tiene que contemplar ese cambio: quien termine haciendo la computación pesada. ¿La arquitectura de Dusk seguirá descentralizada una vez que generar pruebas se vuelva lo suficientemente costoso como para externalizarlo?