Una propuesta que ahora circula entre colaboradores de Zcash, la criptomoneda centrada en la privacidad, eliminaría el mecanismo que invalida las transacciones firmadas pendientes en cada actualización de red (NU), después de que la activación más reciente dejara a las wallets sin poder gastar hasta publicar nuevas versiones o firmware.

Una queja reciente, con un ejemplo reciente

En una publicación en el foro del 9 de noviembre, el desarrollador ValarDragon incluyó la eliminación de las actualizaciones del consensus branch ID entre siete objetivos para NU8, la próxima actualización, con el objetivo declarado de poner fin al patrón de "romper wallets en cada NU".

La queja tiene un ejemplo fresco detrás. NU7 se activó la semana pasada en el bloque 3,543,405 sin modificar el formato de transacciones, y sin embargo, como señaló el miembro del foro strahncryptography en el mismo hilo, cada wallet necesitó una nueva versión o un nuevo firmware antes de poder gastar de nuevo. Cualquier persona con un teléfono aislado de la red o un dispositivo sin soporte quedó bloqueada.

Para la mañana siguiente, el hilo había producido tres posturas: eliminar el mecanismo, mantenerlo pero permitir que los usuarios lo excluyan, o aceptar que el problema real es que las wallets quedan obsoletas, no que las firmas expiran. Un desarrollador de vaults mostró después por qué la elección no es académica.

Qué se rompe realmente

Cada firma de Zcash se compromete con un consensus branch ID, una etiqueta para el conjunto de reglas vigente. ZIP 200, una de las Zcash Improvement Proposals (ZIP) que especifican las reglas del protocolo, lo introdujo para que una transacción firmada para una cadena no pueda reproducirse en una bifurcación que comparte el mismo historial. Cuando se activa una actualización, el ID cambia, y todo lo firmado bajo el anterior queda inválido de inmediato.

El ZIP de despliegue de NU7 lo explica claramente para la actualización que acaba de ocurrir: las transacciones de versión 5 y versión 6 mantuvieron su estructura, pero una transacción sigue sin ser válida a través de la activación porque sus firmas se vinculan al branch ID. Las transacciones guardadas y firmadas sin conexión, añade el documento, necesitan las mismas comprobaciones de activación que las activas.

Por eso las wallets tuvieron que publicar actualizaciones para una actualización que no cambió nada sobre cómo construyen transacciones. Una wallet que no conoce el nuevo ID firma para una cadena que ya no existe.

El vault que no puede firmar a tiempo

Daniel Gorgonha, quien construye el vault t-of-n Konclave en Deega Labs, describió más adelante en el hilo el costo práctico. Konclave construye primero la transacción y recoge después las firmas umbral, por lo que cada firmante requerido debe actuar dentro de la ventana de expiración de la transacción, de aproximadamente 50 minutos. Una actualización que llegue en medio de esa ventana invalida todo.

La cifra de 50 minutos proviene de ZIP 203, que ha mantenido la expiración predeterminada en aproximadamente esa duración a través de tres cambios de tiempo de bloque. Desde NU7, eso significa 120 bloques con el espaciado objetivo de 25 segundos. Es un valor predeterminado de la wallet, configurable por nodo, y una transacción puede construirse sin expiración alguna estableciendo el campo en cero.

Así que el reloj ya tiene solución, al menos donde la wallet expone la configuración. El límite de la actualización no. Un vault podría dar a sus miembros una semana para firmar y aun así perder la transacción en el momento en que el branch ID cambie. La solicitud de Gorgonha fue la opción de exclusión que nuttycom acababa de proponer, para que un grupo pudiera recoger firmas durante horas o días bajo su propio riesgo.

Tres salidas, cada una con una trampa

Eliminar el compromiso del branch ID. Es la propuesta original de ValarDragon. str4d, ingeniero de Electric Coin Company (ECC), respondió que la protección contra replay era un requisito estricto de los exchanges y otros actores del ecosistema cuando se escribió ZIP 200, por lo que cualquier eliminación necesita un mecanismo de reemplazo, idealmente uno que también cubra bifurcaciones hostiles creadas puramente para perturbar la cadena principal.

Mantenerlo como predeterminado y permitir que los usuarios lo excluyan. nuttycom, también de ECC, propuso variantes de firma bajo ZIP 248 que omiten tanto el branch ID como la altura de expiración. Los usuarios que las elijan renuncian a parte de la protección contra replay y obtienen transacciones que sobreviven a una actualización. El algoritmo existente, que según nuttycom funciona bien para la gran mayoría de las transacciones, seguiría siendo el valor seguro predeterminado. str4d ya había señalado que esa variante sería fácil de definir una vez que ZIP 248 esté activo.

Cuestionar si eso resuelve algo para las wallets. strahncryptography argumentó que las variantes corrigen la longevidad de las transacciones, pero no la obsolescencia: si el branch ID no está codificado de forma fija, el usuario debe proporcionar el correcto, lo que devuelve la misma carga al software de la wallet. La protección contra replay contra bifurcaciones amistosas tiene valor, escribió, pero los beneficios deben sopesarse.

El hilo no ha resuelto el desacuerdo. Lo que ha hecho es reducir la pregunta a si vale la pena construir una variante opcional para los usuarios que la necesitan, y qué darían esos usuarios a cambio.

Lo que costaría excluirse

El riesgo de replay es más fácil de imaginar con la actualización que acaba de ocurrir. Solo para NU7, ZIP 259 renunció al requisito habitual de que el software de nodo antiguo se deprecara antes de la activación, lo que significa que los operadores que nunca actualizaron pueden permanecer en línea y seguir una rama previa a NU7. Una transacción cuya firma no está vinculada a una rama es exactamente del tipo que podría aceptarse en ambas.

La exposición es el alcance de una autorización, no las claves detrás de ella. Una transacción reproducida gasta las mismas entradas en otra cadena que el firmante nunca pretendió usar; no permite a nadie forjar una nueva.

Omitir la altura de expiración de la firma tiene un segundo efecto: un pago autorizado puede permanecer sin confirmar mientras sus entradas sigan sin gastarse. Esa es la característica que un vault quiere y el riesgo que un usuario individual puede no notar.

nuttycom también señaló una posible reducción en el conjunto de anonimato. En un sistema protegido, la privacidad depende de que una transacción se vea como cualquier otra; una firmada con una variante poco usada tendría una multitud más pequeña en la que esconderse. La publicación no cuantificó el efecto, y aún no se ha especificado ninguna variante.

Una firma más duradera no actualiza un dispositivo antiguo

ZIP 248, el formato de transacciones extensible del que depende todo esto, sigue siendo un borrador. str4d dijo que su diseño ha sido estable durante más de medio año y que pasó la semana pasada actualizándolo para los cambios de consenso desplegados desde entonces. No se ha asignado a ninguna actualización, y las variantes de exclusión aún no existen en él.

Incluso cuando existan, una wallet de hardware o un firmante sin conexión seguirá necesitando software que entienda el nuevo formato. ZIP 248 prohíbe a las wallets construir o firmar componentes que no pueden interpretar. El beneficio de compatibilidad es real, pero llega a través de versiones de wallets, que es el paso que, según strahncryptography, sigue fallando.

Nada de esto ayuda tampoco a las transacciones en un formato retirado. ZIP 259 señala que la prohibición de NU7 sobre las transacciones de versión 4 cubre los gastos transparentes y de Sapling, además de Sprout, y que volver a firmar no puede rescatarlas; la única solución es reconstruir el pago en una versión con soporte. Coindoo cubrió la semana pasada el caso más difícil: monedas Sprout sin ningún formato de reemplazo.

Konclave también tiene su propia pieza sin terminar. Su issue abierto sobre firma asincrónica separa las aprobaciones recogidas a lo largo del tiempo de la ceremonia interactiva de umbral que el vault ejecuta hoy. Una transacción que sobrevive a una actualización elimina un obstáculo; el flujo de trabajo que permita a los miembros contribuir a medida que se conectan todavía debe escribirse y revisarse.

Orientación práctica

Si administras una wallet grupal:

• La activación es una altura de bloque, no una fecha; el ZIP de despliegue de cada actualización la publica por adelantado.
• No abras una ronda de firma que pueda abarcar esa altura.
• Todo lo preparado antes de la activación debe reconstruirse después, incluso si nadie ha firmado todavía.

Si tienes monedas en un dispositivo antiguo:

• Verifica si su firmware o aplicación ha publicado soporte para NU7 antes de intentar gastar.
• Un gasto atascado desde un pool con soporte es un problema de la wallet, no fondos perdidos.
• Las transacciones de versión 4 guardadas antes del 6 de noviembre no pueden volver a firmarse para volverse válidas.

La revisión anterior de Coindoo sobre mejoras de pagos del lado de las wallets cubrió la brecha entre construir una transacción y confirmarla. Este hilo añade una tercera etapa intermedia: mantener viva la autorización mientras las personas y los dispositivos se ponen al día.

Qué sigue

Finales de enero es la meta de ValarDragon, no un cronograma. str4d cuestionó en el mismo hilo si dos meses y medio son suficientes para el pool Tachyon de la misma lista, y el punto del branch ID ha recibido la mayor resistencia de los siete. Si NU8 incluirá una opción de exclusión, un reemplazo para la protección contra replay, o ninguno de los dos, se decidirá en el proceso de ZIP, no en el foro.