Por: Zooko Wilcox, Jason McGee y Taylor Hornby de Shielded Labs
Resumen
Shielded Labs está trabajando con The Zcash Foundation, Tachyon Group, Valar Group y el Zcash Open Development Lab (ZODL) en una propuesta llamada "Ironwood" para restaurar la capacidad de los usuarios de verificar la solidez de la oferta circulante de Zcash.
La semana pasada, se descubrió una vulnerabilidad crítica de falsificación en el pool Orchard de Zcash. La vulnerabilidad fue corregida mediante una actualización de emergencia de la red coordinada por ZODL y otros participantes del ecosistema, y se completó el 2 de junio.
Aunque creemos que era improbable que la vulnerabilidad hubiera sido explotada (por las razones expuestas en nuestra divulgación), las propiedades de privacidad de Orchard impiden que los usuarios lo verifiquen por sí mismos.
Ironwood permitiría a los usuarios verificar que la oferta circulante de Zcash es correcta. Los usuarios obtendrían esta capacidad inmediatamente después de la activación de Ironwood, simplemente sumando los saldos de los pools activos. No necesitarían razonar sobre los incentivos o acciones de otras personas, ni esperar la migración desde el pool Orchard, para verificar que la oferta circulante total de Zcash es correcta.
Ironwood
El objetivo de Ironwood es restaurar la capacidad de cada usuario de Zcash para verificar la integridad de la oferta de Zcash. Esta verificabilidad se vio afectada por la existencia de la vulnerabilidad de falsificación. Inmediatamente después de la activación, los usuarios podrán verificar de forma independiente que la oferta circulante de Zcash es sólida, simplemente ejecutando un nodo.
Para lograrlo, Ironwood:
- Crearía un nuevo pool blindado utilizando el circuito Orchard con la reciente vulnerabilidad de falsificación corregida.
- Rechazaría como inválida cualquier transacción que cree una nueva salida en el antiguo pool Orchard.
- Aumentaría la confianza en el código base, utilizando técnicas como la auditoría de seguridad asistida por IA y la verificación formal, todo ello orientado a garantizar la ausencia de errores de falsificación adicionales.
Por qué funciona Ironwood
Ironwood cambia lo que puede suceder dentro del pool Orchard.
Tras la activación, cualquier transacción que cree una nueva salida en el pool Orchard sería rechazada. Esto significa que ZEC ya no podría seguir circulando dentro de ese pool. A partir de ese momento, los fondos en el pool Orchard solo podrían moverse saliendo del pool a través de un torniquete.
Los torniquetes son el mecanismo contable en cadena de Zcash para las transferencias entre pools. Realizan un seguimiento de cuánto ZEC ha entrado y salido de cada pool y rechazan cualquier transacción que intente sacar más ZEC del que entró legítimamente.
En conjunto, estas reglas significan que los usuarios no necesitan esperar a que migren todos, o incluso algunos, los fondos de Orchard. Tan pronto como Ironwood se active, los usuarios pueden verificar a partir de las reglas de consenso que no puede estar circulando más de la cantidad correcta de ZEC. Esto proporciona una garantía inmediata y sin confianza de la solidez de la oferta circulante de Zcash. El exceso de ZEC no puede circular en secreto entre los usuarios del pool Orchard, ni puede escapar a otro pool.
Generación de evidencia sobre si la vulnerabilidad fue explotada o no
Ironwood también puede proporcionar evidencia sobre si la vulnerabilidad de Orchard fue explotada alguna vez, pero lograr su objetivo no depende de que surja dicha evidencia.
A medida que los usuarios migren fondos del pool Orchard existente al nuevo pool, cualquier falsificador hipotético se enfrenta a una elección: intentar mover fondos falsificados y arriesgarse a exponer su existencia, o dejarlos atrás y arriesgarse a no poder moverlos en el futuro.
Esto crea dos resultados posibles:
Resultado A: Ningún exceso de ZEC intenta salir del pool Orchard existente. Esto sería una fuerte evidencia de que la vulnerabilidad nunca fue explotada, ya que un falsificador tendría un fuerte incentivo para mover los fondos falsificados antes de que los usuarios legítimos completaran sus migraciones.
Resultado B: El exceso de ZEC intenta salir del pool Orchard existente. En este caso, los fondos excedentes no podrían salir del pool y quedarían efectivamente destruidos. Desafortunadamente, esto es necesario para preservar la oferta circulante actual en todos los pools. Esto también proporcionaría evidencia verificable públicamente de que se había producido una falsificación. Como creemos que la vulnerabilidad no fue explotada, pensamos que este resultado es poco probable.
Billeteras
Recomendamos que todas las billeteras que admiten el pool Orchard existente agreguen soporte para el nuevo pool.
Las billeteras deben continuar admitiendo el pool Orchard existente con normalidad hasta la activación de Ironwood, y luego migrar los fondos de los usuarios del pool Orchard existente al nuevo pool. Si bien la migración tiene implicaciones para la privacidad (a saber, expone la cantidad de ZEC transferido y el momento en que se realizó la transferencia), creemos que el impacto en la privacidad del usuario es moderado y puede mitigarse aún más con el comportamiento de la billetera.
Los receptores Orchard existentes (es decir, las direcciones) siguen siendo válidos y no sería necesario rotarlos. El ZEC enviado a receptores Orchard creados antes de la activación de Ironwood se recibiría automáticamente como ZEC en el nuevo pool.
Cronograma
Como la mayoría de las actualizaciones de red, Ironwood requerirá desarrollo, pruebas, revisión y coordinación en todo el ecosistema. La experiencia ha demostrado que este trabajo a menudo lleva más tiempo del esperado, por lo que creemos que es mejor ser conservadores al hablar de los plazos que prometer de más y no cumplir.
Una fuente adicional de incertidumbre es la descontinuación en curso de zcashd. Si bien Shielded Labs no ha participado directamente en ese esfuerzo, la migración de exchanges, pools de minería, billeteras y otros proveedores de infraestructura a Zebra puede afectar el cronograma de esta actualización de red.
Esperamos tener una mejor comprensión del cronograma a medida que los planes de implementación maduren y continúen las discusiones.
Conclusión
Queremos enfatizar que creemos que la explotación previa de la vulnerabilidad de Orchard es poco probable. Pero los usuarios no deberían tener que confiar en nuestra evaluación, ni en la de nadie más, cuando se trata de la integridad de la oferta de Zcash.
Ironwood está diseñado para restaurar una garantía de la oferta circulante de Zcash que cualquiera pueda verificar por sí mismo. Ya sea que la vulnerabilidad haya sido explotada o no, el objetivo es el mismo: hacer que la integridad de la oferta de Zcash sea algo que se pueda verificar.
Creemos que Ironwood es el mejor camino a seguir y esperamos discutir esta propuesta con la comunidad de Zcash.
Agradecimientos
Gracias a Sean Bowe, Dev Ojha, David Campbell, Alex Bornstein, Nate Wilcox, Kris Nuttycombe, Vitalik Buterin, Balaji Srinivasan, y Taylor Hornby, Josh Swihart y Tatyana por la revisión y los comentarios. Especialmente gracias a Kris Nuttycombe por sugerir que la actualización Ironwood deshabilite las transacciones que crean salidas en el antiguo pool Orchard. Esto resulta ser fundamental para que Ironwood logre su objetivo.
