Investigadores de [[alloc] init] —Clara Shikhelman, Misha Komarov y Aleksei Moskvin— han presentado Shielded Bitcoin, un whitepaper que describe un novedoso metaprotocolo de privacidad construido sobre la capa base de Bitcoin. El diseño permite transacciones blindadas de Bitcoin sin requerir operadores, soft forks ni ningún otro cambio en el consenso de Bitcoin. El whitepaper y un anuncio en el blog están disponibles, y el equipo compartió la noticia en X.

El protocolo define una estructura transaccional y un protocolo de indexación para transacciones con fuerte preservación de la privacidad, al tiempo que se apoya en Bitcoin PIPEs para mover fondos hacia dentro y fuera del sistema. El mecanismo de PIPEs se examina en detalle al final de este artículo.

La propiedad de no requerir cambios de consenso es relevante: el registro de Bitcoin anota montos y direcciones a la vista pública, y los cambios en sus reglas históricamente han requerido una amplia coordinación en toda la red. Un diseño que opera por completo dentro del conjunto de reglas existente no depende de ese proceso para avanzar.

Un diseño similar a Bitcoin con detalles muy distintos

La arquitectura deliberadamente refleja la de Bitcoin. Existe un equivalente al UTXO, llamado nota. Las transacciones consumen notas como entradas, igual que una transacción regular de Bitcoin gasta UTXOs. Un testigo (witness) demuestra que las entradas consumidas están debidamente autorizadas, y los nodos —indexadores, en el caso de un metaprotocolo— analizan el historial de transacciones y construyen un estado continuo de qué monedas están gastadas y cuáles no.

Sin embargo, cada detalle subyacente es bastante diferente.

Transacciones que el propio Bitcoin ignora

Una transacción de Shielded Bitcoin es simplemente un blob de datos que lleva un prefijo —algo como "shbtc:"— incrustado en unaacción de Bitcoin mediante OP_RETURN, el campo witness u otro método de transporte de datos. Este es el patrón del metaprotocolo: las reglas del protocolo son aplicadas por sus propios indexadores y no por Bitcoin, por lo que la cadena base no ve nada más allá de datos ordinarios. El blob no tiene significado para Bitcoin: la red no hace nada para verificarlo ni aplica regla alguna contra él.

Como resultado, es perfectamente posible que transacciones inválidas de Shielded Bitcoin terminen en la cadena. Corresponde a un Indexador de Shielded Bitcoin, que observa pasivamente la blockchain, ignorar las transacciones que fallan la validación y negarse a aplicarlas al actualizar el estado de los saldos de la red.

Nullifiers en lugar de un conjunto de gastados

Un indexador no elimina notas de un conjunto de notas no gastadas como Bitcoin elimina los UTXOs gastados. En cambio, mantiene un conjunto de nullifiers. Este mecanismo permite a un usuario publicar públicamente una prueba cifrada y un nullifier que muestran que una nota ha sido gastada sin revelar cuál fue gastada. En lugar de verificar si una nota está en el "conjunto de notas no gastadas", los participantes comprueban si un determinado nullifier ya fue utilizado.

Los indexadores construyen un árbol de Merkle que crece indefinidamente y solo puede recibir elementos, que contiene cada salida de nota jamás creada, junto con el conjunto de nullifiers.

Ejecutar el protocolo solo requiere un nodo

Usar el protocolo no requiere nada más que un nodo de Bitcoin y un indexador de Shielded Bitcoin. No se necesita ningún servicio, coordinador ni estado fuera de la cadena para recuperar fondos. Funciona igual que Bitcoin en la cadena: lo único que un usuario necesita es su nodo/indexador y sus claves.

Cada billetera de usuario deriva una clave secreta maestra, de la cual se crean todos los demás conjuntos de claves involucrados —un diseño que se asemeja mucho a una billetera HD en Bitcoin, de la cual se pueden generar muchos conjuntos de direcciones. sk_spend actúa como la clave privada de gasto, sk_nf se usa para anular salidas de notas, vk_in descifra y visualiza las notas entrantes, vk_out visualiza las transacciones salientes, y sk_view genera una dirección de recepción.

Cuando un usuario quiere entregar a alguien una dirección para recibir fondos, genera un valor diversificador d, similar a un valor de derivación, y lo multiplica por su clave sk_view. La clave pública resultante pk_d, junto con d, constituye la dirección del usuario.

El remitente genera entonces un valor aleatorio, el r_seed, necesario tanto para cifrar la salida de la nota como para la anulación. Las salidas de la transacción contienen solo tres elementos cifrados: el valor de la salida, el valor d que el receptor entregó al remitente y el valor r_seed del remitente. Para cifrar, el remitente utiliza un par de claves efímeras secretas y la clave pública del receptor para crear un secreto compartido —ambas partes pueden calcular el mismo secreto multiplicando su clave privada por la clave pública de la otra. La salida de la nota cifra con este secreto compartido, y la clave efímera sk_eph se incluye sin cifrar para que el receptor pueda generar el secreto compartido por sí mismo.

Las pruebas de conocimiento cero garantizan la validez

En el lado de las entradas, se requieren dos cosas para que una transacción sea válida: un nullifier público por cada salida de nota consumida y una prueba de conocimiento cero que demuestre que (1) la salida de la nota está incluida en el árbol de Merkle de notas, (2) la transacción está autorizada por la clave sk_spend apropiada, (3) el nullifier está correctamente derivado, y (4) no se ha producido inflación.

El nullifier incorpora la clave sk_nf, un valor ρ derivado del r_seed y la posición de la nota en el árbol de Merkle de salidas de notas. Aunque nadie puede saber a qué salida de nota corresponde un nullifier, las pruebas de conocimiento cero en cada transacción garantizan que cada nullifier añadido al conjunto proviene de una salida de nota válida. Por lo tanto, los indexadores simplemente pueden rechazar los nullifiers repetidos en lugar de eliminar las notas gastadas, y mientras no haya repeticiones, el sistema ofrece la misma garantía contra el doble gasto.

El efecto neto es que las transacciones cifradas del metaprotocolo pueden incrustarse en la blockchain de Bitcoin, garantizando al mismo tiempo que nada se gaste dos veces y que las monedas no se inflen de la nada.

Propiedades de privacidad

Según el análisis, el sistema está bien diseñado en términos de propiedades de privacidad y está a la altura de algo como los shielded pools de Zcash. La comparación esboza el panorama más amplio: Zcash ofrece transacciones blindadas mediante reglas integradas en su propio protocolo, mientras que este diseño busca propiedades comparables en la capa base de Bitcoin sin tocar el consenso. Las consideraciones de privacidad que surgen al entrar y salir del metaprotocolo se detallarán en un próximo documento, dejando los puntos de entrada y salida del sistema entre los detalles a observar a medida que el trabajo avance. A diferencia de los coinjoins, no hay preocupación por medir la privacidad ni necesidad de remezclas periódicas.

Moviendo fondos con PIPEs v2

El peg previsto se basa en PIPEs v2, un esquema de cifrado testigo. PIPEs permiten cifrar una clave privada con un programa o mecanismo que no revelará la clave a menos que se proporcione una prueba ZK que demuestre que se ha cumplido cierta condición —por ejemplo, el estado de algún UTXO, o que una transacción ha sido confirmada. Esto permitiría que un peg funcione sin un operador, una federación ni ningún tercero que custodie los fondos —una propiedad destacable, ya que los diseños de peg que extienden Bitcoin tradicionalmente han dependido de tales custodios. No requiere soft forks ni cambios de protocolo en Bitcoin y ocurre por completo fuera de la cadena.

La siguiente fase del trabajo del equipo es un mecanismo de peg que permitiría a los usuarios depositar fondos en Shielded Bitcoin utilizando claves controladas criptográficamente por PIPEs, que luego serían "desbloqueadas" generando una prueba ZK de transacciones de peg-out legítimas confirmadas en la cadena. Actualmente se trabaja en el documento que define este aspecto del sistema, que debería publicarse en un futuro cercano; junto con el documento sobre la privacidad de entrada/salida, completará las piezas que el whitepaper deja abiertas.

---

Este artículo, escrito por Shinobi, apareció por primera vez en Bitcoin Magazine.