Loading...
Este artículo se reproduce de Proof Street, una publicación independiente que cubre la computación que preserva la privacidad: ZK, FHE, MPC, TEEs e identidad descentralizada. Publicado originalmente como "Hasta dónde ha llegado Zcash en materia de divulgación selectiva y qué falta" el 7 de septiembre de 2026. Reproducido con el permiso del autor como parte de la Zcash Community Grant #339. Por Stephen Webber.
En Zcash, una viewing key permite al titular de una cuenta revelar el historial de transacciones blindadas a una parte de su elección. Las claves están activas y controladas por el usuario. Los desarrolladores y defensores de políticas todavía trabajan para que sirvan a los flujos de cumplimiento que podrían utilizarlas.
El 17 de agosto, el comité de Zcash Community Grants se reunió para considerar una propuesta llamada Shielded Compliance Bridge. Deborah Olaboye, una colaboradora de código abierto cuyo trabajo incluye el repositorio execution-specs de Ethereum, había creado una prueba de concepto que recibe una unified full viewing key, analiza bloques compactos frente a un indexador de testnet y lleva una "referencia de cumplimiento" en un campo memo de Zcash que vincula una transferencia blindada con un registro off-chain de la Travel Rule. Solicitó una subvención para terminarlo, pero el comité la rechazó.
El razonamiento fue que las integraciones de cumplimiento se configuran según el exchange o institución concreta que las utilizará, que no existen estándares comunes sobre los cuales construir y que, sin un socio que solicite la herramienta, la adopción era poco probable. En la misma reunión se rechazaron otras propuestas por razones similares: una para una máquina virtual de "divulgación selectiva programable" y otra para un marco de arquitectura de privacidad y confianza, que incluía un mapa de cuestiones legales de EE. UU.
Por supuesto, estas decisiones no indican que nadie quiera esto. Consideradas junto con el resto del año, indican lo contrario. Binance realizó una solicitud a nivel de protocolo en 2024 y tuvo una ZIP dentro del año. Gemini ha gestionado retiros blindados bajo supervisión regulatoria desde 2020. El ecosistema creó una organización de políticas públicas en Washington en junio y una firma de integración institucional en agosto. Lo que el comité dijo, en efecto, es que la necesidad todavía no se ha redactado como un requisito sobre el que alguien pueda construir.
Una dirección blindada de Zcash está controlada por una spending key. De ella se derivan viewing keys que pueden leer datos de transacciones sin poder mover fondos. La full viewing key ve las transacciones entrantes y salientes de la cuenta; la incoming viewing key solo ve los fondos recibidos; y la outgoing viewing key permite a un remitente reconstruir lo que envió. Desde ZIP 316, estas se agrupan en unified viewing keys, una completa y otra entrante, limitadas a una cuenta, donde una cuenta es una posición en el árbol de claves del wallet bajo ZIP 32. Una unified full viewing key agrupa los componentes por pool para cada pool blindado que utiliza la cuenta, y también contiene la clave pública extendida transparente de la cuenta, por lo que compartir una expone la cadena transparente además del historial blindado.
En este sentido, una viewing key es retroactiva. Descifra todo el historial de la cuenta desde el momento en que se creó, y no puede retirarse una vez compartida, salvo moviendo los fondos a una cuenta nueva. No hay una viewing key por transacción ni una con límite temporal. Josh Swihart, director ejecutivo de ZODL, la empresa formada este año por el antiguo equipo de ingeniería de ECC del protocolo, confirmó esto y también mencionó que la divulgación de pagos por transacción "no está implementada en ninguna parte".
zcashd, el nodo de referencia original, incorporó dos métodos RPC, z_getpaymentdisclosure y z_validatepaymentdisclosure, que permiten a un remitente demostrar un pago único a un tercero. La documentación de RPC los marca como experimentales, desactivados salvo que el operador establezca una opción de funcionalidades experimentales, e implementando una "Payment Disclosure ZIP en proceso". Esa ZIP, 303, ahora está marcada como retirada, y su sucesora, ZIP 311, sigue siendo un borrador sin implementación asociada. Los métodos solo cubrían el pool Sprout, el pool blindado original de 2016, y nunca se extendieron a Sapling ni a Orchard; es decir, a los pools que transportan todas las transacciones blindadas modernas. El propio zcashd llegó al final de su vida útil el 18 de julio de 2026, una detención planificada antes de la actualización Ironwood. Ni Zebra, el nodo de consenso de Zcash Foundation, ni Zallet, el wallet sucesor, enumeran un método de divulgación. Para los pools que importan, la divulgación por transacción sigue siendo una intención de diseño.
La intención sigue vigente, pero está más lejos de lo que parecía en julio. ZIP 231, los paquetes memo, es el borrador que abriría espacio para ello: Swihart describió los paquetes memo como la base eventual para una dirección de respuesta autenticada que podría funcionar como prueba de pago, y el borrador dependiente, direcciones de respuesta autenticadas, necesita pruebas demasiado grandes para el campo memo actual. Los paquetes memo son un cambio de formato de transacción, y las cinco organizaciones que coordinan la NU7 votación de coinholders acordaron en agosto que los cambios de formato quedan fuera del alcance de NU7 y dentro del alcance de la actualización posterior. La votación en sí, que se celebra del 25 de agosto al 14 de septiembre, puso ante los titulares la emisión, la política de comisiones, el espaciado de bloques y la desactivación de Sprout; la divulgación no estaba en la papeleta. La ruta más antigua, ZIP 311, no necesita ningún cambio de consenso, pero continúa siendo un borrador sin implementación ni cobertura de Orchard.
Así que lo que se ofrece hoy son viewing keys con alcance de cuenta, completas o solo entrantes, retroactivas, irrevocables y compartidas por iniciativa del titular de la cuenta, con la divulgación a nivel de transacción en la hoja de ruta.
Los mecanismos de divulgación, en Zcash o en cualquier otro lugar, pueden situarse según lo siguiente: qué se revela (alcance); a quién (beneficiario); cuándo la autorización entra en vigor y hasta qué punto se remonta (temporalidad); si puede retirarse (revocabilidad); y quién la inicia, el sujeto de los datos o una autoridad (iniciación).
Los regímenes de cumplimiento son requisitos sobre estas dimensiones, y las arquitecturas son posturas frente a ellas. Las viewing keys de Zcash tienen por diseño un alcance amplio, un beneficiario elegido por el titular, son completamente retroactivas, irrevocables e iniciadas por el usuario. El lado de los requisitos, tal como lo aplican los exchanges y supervisores, tiende a limitarse a una relación o un período, concederse a una institución identificada o a su proveedor de analítica, ser continuo desde la incorporación en adelante, revocable cuando termina la relación e iniciado por la institución como condición de servicio.
Ambas cosas reciben el nombre de divulgación selectiva. En el mundo de las credenciales, divulgación selectiva significa presentar un subconjunto de atributos de una credencial firmada sin revelar el resto, que es para lo que se han creado SD-JWT, ISO mdoc y las firmas BBS+. La unidad de divulgación es un atributo, el momento es el de la presentación y el titular decide en cada interacción.
En el mundo de los pagos blindados, la expresión significa revelar datos de transacciones a una parte elegida, donde la unidad es el historial de una cuenta y el momento es aquel en que se entrega la clave.
Swihart dijo que la única solicitud de cumplimiento a nivel de protocolo que el equipo de ingeniería ha recibido provino de Binance, que en enero de 2024 exigió una garantía de procedencia transparente para los depósitos. La respuesta del equipo fue ZIP 320, direcciones de origen únicamente transparente, y el texto de ZIP de hecho registra el origen "según lo requerido por Binance". Una dirección TEX es un paso efímero transparente que garantiza que el exchange reciba fondos de una fuente transparente. Le da al exchange una ruta de retorno sin entregarle el historial del remitente. La única adaptación que el protocolo hizo para un exchange revela exactamente lo que el exchange pidió y nada más.
Desde la actualización de Sapling, argumenta Swihart, no ha habido una razón técnica para que un exchange no admita transacciones blindadas, porque las pruebas se generan rápido, los clientes de los exchanges ya se identifican en la incorporación y existe debida diligencia reforzada para los casos que la necesitan. Desde ese punto de vista, la distancia entre la infraestructura y el flujo de cumplimiento no es realmente una primitiva ausente, sino una conversación ausente.
Divij Pandya trabaja en el otro extremo de esa conversación. Es director ejecutivo de Pretty Good Policy para Zcash, la organización de políticas públicas de Washington creada en junio como continuación de una iniciativa anterior liderada por ECC, y el proyecto de su organización es lograr que la divulgación mediante viewing keys sea reconocida como un mecanismo de cumplimiento aceptable en un documento que un responsable de cumplimiento pueda citar. Según su conocimiento, dijo, ningún regulador ha tratado todavía las viewing keys como instrumento. El alcance de PGPZ es, naturalmente, el reconocimiento y no la guía para desarrolladores. No se puede especificar una herramienta frente a un requisito hasta que alguien con autoridad haya dictaminado sobre el instrumento, por lo que el reconocimiento es el paso previo. Las declaraciones de la organización están firmadas por Paul Brigner como fundador de PGPZ y como director de políticas públicas y regulación de ZODL, por lo que los esfuerzos de políticas e ingeniería comparten un directivo además de una tesis.
Una declaración del 21 de julio para el registro ante un subcomité de la Cámara sobre la supervisión de FinCEN describe a Zcash como dotado de "capacidades de divulgación selectiva, que permiten a los usuarios compartir voluntariamente detalles de transacciones mediante el uso de viewing keys con auditores, autoridades fiscales o responsables de cumplimiento", y se refiere a pruebas de conocimiento cero "combinadas con viewing keys selectivas" para probar hechos específicos. Una carta de comentarios en el expediente de FinCEN, FINCEN-2026-0101-0050, sostiene, según Pandya, que las viewing keys y la divulgación selectiva deberían ser mecanismos de cumplimiento aceptables. La cuestión abierta que plantean al regulador es la granularidad: si la divulgación de toda la historia con alcance de cuenta basta para la "información de transacciones específica", o si la respuesta espera a ZIP 231.
Hasta que eso se resuelva, los equipos de cumplimiento enfrentan una restricción que un participante seudónimo del foro, strahncryptography, describió en la discusión de la propuesta de Olaboye: siguen la norma al pie de la letra y no adoptarán una vía no reconocida sin la certificación de un regulador o un bufete de abogados, por sólida que sea la criptografía. Cualquier diseño de divulgación que adjunte una referencia a una transacción prueba únicamente el último salto, y el último salto podría ser el propio depositante. Una viewing key tiene el mismo límite. Revela las transacciones del titular de la cuenta, no de dónde procedieron los fondos de las contrapartes, que es la pregunta que plantea una evaluación de sanciones.
Las viewing keys superan el umbral cuando el requisito es una prueba por parte del sujeto de datos sobre lo sucedido, como la procedencia de un depósito que el depositante decide explicar, una auditoría voluntaria, una declaración fiscal o una prueba de que se realizó un pago específico. Estas son divulgaciones únicas, retroactivas e iniciadas por el usuario. No superan el umbral cuando el requisito es la monitorización continua desde la incorporación en adelante, la evaluación de sanciones contra contrapartes que el titular de la cuenta no controla, la limitación a un período o una relación, o la revocación al terminar la relación.
Gemini ha aceptado retiros a direcciones blindadas desde septiembre de 2020, cuando un portavoz atribuyó el hecho a conversaciones continuas con los reguladores; extendió esto al pool Orchard en noviembre de 2025 y al pool posterior a Ironwood dos días después de la activación en julio de 2026. Acepta depósitos enviados desde direcciones blindadas a custodia transparente. La lista de direcciones de retiro de Kraken admite únicamente direcciones transparentes de ZEC, Coinbase también admite únicamente direcciones transparentes y Binance requiere TEX. Lo que ningún exchange regulado importante ofrece todavía es custodia blindada, una dirección de depósito blindada o un flujo de trabajo al que se incorporaría la viewing key de un cliente.
La ingesta se está construyendo un nivel más abajo. Entre las propuestas de la ronda de subvenciones retroactivas dirigidas por coinholders en revisión este septiembre se encuentran ZecBooks, una herramienta de contabilidad para Mac que importa una clave de solo visualización, clasifica notas y exporta un paquete delimitado de filas para un contador sin otorgar acceso duradero al wallet; ZecLedger, una herramienta de solo lectura para base de coste y conciliación construida alrededor de una unified full viewing key, probada frente a un wallet de mainnet; y seer-sync, un motor de sincronización de cadena que recibe una viewing key para que un procesador de pagos o sistema contable pueda observar actividad blindada sin poseer spending keys. Ninguna es un flujo de trabajo de exchange y ninguna cuenta con la atención de un regulador. Cada una constituye la mitad orientada al contador del mismo problema, construida por una o dos personas sin que un socio la solicite, y la exportación delimitada de ZecBooks es divulgación selectiva operando en la interfaz donde suele necesitarse primero: entre un usuario blindado y la persona que lleva su contabilidad.
Los desarrolladores de Zcash trabajan en un problema compartido por toda arquitectura de privacidad.
En el diseño EVM confidencial de Zama, una lista de control de acceso determina qué direcciones pueden solicitar el descifrado de un texto cifrado, y una red de umbral de operadores de gestión de claves realiza el descifrado a petición. Esto traslada el eje del beneficiario de una clave que entrega el usuario a un permiso que registra un contrato, y hace programable la iniciación, ya que un contrato puede conceder a un auditor derechos de descifrado como condición de uso. No hace revocable la divulgación en el sentido que entiende un responsable de cumplimiento, porque un texto cifrado ya descifrado permanece descifrado, y sustituye la custodia de claves del usuario por la honestidad de los operadores como base de confianza. Las claves de auditor a nivel de activo, del tipo de la extensión de transferencias confidenciales de Solana y el diseño ERC cifrado de Avalanche, fijan un beneficiario a nivel de token, pues el emisor o un auditor designado puede leer los saldos y transferencias de ese activo.
Inco ha publicado un marco para la visualización predefinida, donde el acceso queda fijado en el material de claves en el momento de la transacción, frente al acceso de visualización programable, donde los derechos de visualización son estado del contrato que puede concederse, delimitarse y retirarse después.
¿Qué separa una viewing key de un flujo de cumplimiento?
Una viewing key revela el historial propio del titular de la cuenta. La evaluación de sanciones y la monitorización continua preguntan por las contrapartes, de dónde procedían los fondos del otro lado de cada transacción, y esa es precisamente la información que existe un pool blindado para ocultar. Nadie ha mostrado todavía un diseño que responda a una pregunta sobre una contraparte sin un registro transparente o un tercero de confianza.
Si los paquetes memo llegan en la actualización posterior a NU7 y sigue el borrador de direcciones de respuesta, la "información de transacciones específica" de las declaraciones de PGPZ se vuelve literal. Eso está al menos a dos actualizaciones de distancia, y la respuesta regulatoria llegará según el calendario de un regulador.
La demanda se observa fácilmente por la cantidad de personas que trabajan para satisfacerla. Lo que falta es un requisito fijo para la divulgación que preserva la privacidad. Zcash es el ecosistema donde esa decisión se negocia abiertamente, por ingenieros, defensores, desarrolladores, un exchange y un comité de subvenciones que parecen estar de acuerdo sobre el destino y discuten el orden de los pasos. También trabajan en ello desarrolladores independientes que comenzaron por la capa contable sin esperar a que se redactara el requisito.
Divulgación: este artículo contó con el apoyo de una Zcash Community Grant. ZCG no revisó ni aprobó este artículo antes de su publicación.
Páginas relacionadas: Viewing Keys · Confidencialidad comparada