Vista previa para desarrolladores: Stellar Private Payments

Nota del editor: Las Vistas Previas para Desarrolladores de Stellar ponen nuevas herramientas para desarrolladores y capacidades de protocolo en manos de los desarrolladores antes de que estén listas para producción. Aunque aún no están aprobadas para mainnet, el contrato de Stellar Private Payments ya está disponible en testnet. Previsualízalos y pruébalos ahora mientras los contratos no están auditados y el desarrollo está en curso.

Hoy estamos presentando Stellar Private Payments (SPP), un primitivo de privacidad en Stellar. Stellar Private Payments es una implementación de pool de privacidad desarrollada por Nethermind que brinda privacidad a nivel de contraparte para los pagos. Los usuarios mantienen un saldo privado en un pool compartido protegido y se pagan entre sí dentro de él. El libro mayor público registra que se usó el pool, manteniendo en privado quién pagó a quién o cuánto. Como destaca Nethermind en su artículo; la privacidad y el cumplimiento no son requisitos opuestos y SPP está diseñado para hacer cumplir ambos, sobre rieles públicos.

Algo que vale la pena reiterar de nuestra última Vista Previa para Desarrolladores sobre Confidential Token: La privacidad en una blockchain pública no es una sola cosa. Diferentes casos de uso necesitan propiedades distintas, y la arquitectura que elijas al inicio decide lo que podrás hacer después.

Mientras que un Confidential Token mantiene montos y saldos entre contrapartes conocidas en privado, Stellar Private Payments proporciona privacidad para contrapartes. Las direcciones de depósito y retiro son visibles en los bordes del pool; puedes ver que entraron y salieron fondos, pero el vínculo entre un depósito específico y un retiro específico, y el monto y las contrapartes de cualquier transferencia dentro del pool, se mantienen privados para el público. Los casos de uso adecuados incluyen pagos B2B o donaciones donde la relación entre las partes que realizan la transacción es sensible.

Esta publicación se centra en Stellar Private Payments, para flujos donde las contrapartes necesitan privacidad.

El pool es el lugar donde viven los fondos y ocurren las transacciones. Un usuario deposita un activo en un contrato de pool compartido, y su depósito se convierte en un compromiso en un árbol de Merkle, una nota criptográfica que prueba que existe valor en el pool sin revelar de quién es.

Desde ahí, el evento principal es la transferencia privada dentro del pool. Cuando pagas o transfieres fondos a otra dirección dentro del pool, tus notas se gastan y se crean nuevas notas bajo la clave del destinatario. Cada operación que gasta notas, ya sea una transferencia o un retiro, publica una prueba de conocimiento cero que dice: “las notas que estoy gastando son válidas y me pertenecen,” sin revelar cuáles notas son. Se publica un anulador onchain al mismo tiempo para que la misma nota nunca pueda gastarse dos veces. Los usuarios pueden mantener un saldo privado indefinidamente y pagar a muchas contrapartes antes de salir del pool.

En un pool que usa SPP, puedes pagar a alguien usando una G-dirección de Stellar y compilaciones recientes de desarrolladores del ecosistema han demostrado pagos en testnet a C-direcciones de Stellar con cuentas inteligentes (demo de Privacy Wallet).

Y luego está retirar, que es simplemente la salida. Demuestra tus notas y mueve el valor de vuelta al libro mayor público a una dirección de tu elección.

Para hacerlo tangible, veamos un ejemplo de transacción. Lo que debes buscar onchain que cuenta la historia es ext_amount, el monto externo en una transacción del pool:

• Depósito: ext_amount es positivo (p. ej., +50000000 stroops = 5 XLM). Los fondos que entran son públicos.
• Transferencia privada: ext_amount es 0. El monto se mueve completamente dentro de compromisos cifrados, y la dirección del destinatario aparece en ninguna parte en la transacción.
• Retiro: ext_amount es negativo (p. ej., −20000000). El monto que sale es público en el libro mayor.

Entrada pública, parte media privada, salida pública, sin nada onchain que ate los dos extremos. El sistema de pruebas de conocimiento cero usado es Groth16, con verificación eficiente en recursos onchain usando las funciones criptográficas del host introducidas en Protocolo 25 (X-Ray) y Protocolo 26 (Yardstick). La propia red verifica cada prueba; no hay verificador u operador de terceros en quien confiar.

Stellar Private Payments y la demo tienen una implementación funcional en testnet contra la que puedes desarrollar hoy.

A los pools les encanta la multitud

Los pools de privacidad demuestran todo su potencial en un pool concurrido. El escenario donde mejor aplica: tener más depósitos de múltiples cuentas en el mismo pool aumenta el “conjunto de privacidad”, haciendo más difícil para un observador público asociar una transacción dada a una sola parte. Por ejemplo, si solo hay dos personas en un pool, tú depositas 5 XLM y, momentos después, alguien retira 5 XLM, un observador puede correlacionarlo por monto y tiempo.

Esta vista previa incluye mecanismos configurables diseñados para ayudar a los implementadores a abordar obligaciones de cumplimiento en sus implementaciones de pools de privacidad.

• Proveedores de Conjuntos de Asociación (ASP), configurables por pool. Stellar Private Payments implementa actualmente un basado en claves modelo de conjunto de asociación, un enfoque diferente del whitepaper de Privacy Pools, que es basado en depósitos. Cuando se implementa un pool, un solo indicador define su modo: block-list (excluir cuentas específicas), allow-list (admitir solo cuentas específicas), o ambos. Cada transacción del pool (depósito, transferencia y retiro) entonces prueba pertenencia o no pertenencia a través de un proveedor de conjunto de asociación designado sin revelar el historial del usuario. Debido a que la asociación es a nivel de clave, no de nota, es más fácil controlar la entrada con KYC y congelar automáticamente cada nota perteneciente a una clave marcada. La demo alojada corre en block-list-only modo, así que cualquiera puede probarla sin incorporación al ASP. El etiquetado y rastreo de depósitos a nivel de nota, basados en el diseño original de Privacy Pools, están en diseño para extender la aplicación a fondos ya transferidos a otros usuarios en el pool.
• Claves de Vista Global. Opcionalmente, proporciona visibilidad a nivel de pool para los administradores en todas las transacciones dentro del pool mediante una cuenta de auditor designada. Esto ayuda a los administradores con obligaciones de cumplimiento como monitoreo y reportes de transacciones y puede asistirles en investigaciones regulatorias cuando se requiera. La clave de vista global puede asegurarse con una solución de billetera institucional e incluso permanecer dentro de un entorno de ejecución confiable para la divulgación segura solo de los datos de transacción relevantes y acotados.
• Divulgación Selectiva, habilitada por claves de vista del usuario. Un usuario puede probar hechos a nivel de nota sobre una transacción específica (monto, compromiso, estado de gasto) a una parte que elija mediante una prueba ligada al contexto, sin exponer el resto de su actividad. Hoy esta divulgación está delimitada a la nota: no prueba el origen de fondos ni el historial de transacciones, por lo que aún no es una atestación que un usuario pueda entregar a un tercero para garantizar la integridad y completitud de la transacción, aunque esto es un objetivo a corto plazo del proyecto.
• Implementación de testnet integrada. Todos los IDs de contratos (pool, verificador Groth16, contratos de membresía y no membresía de ASP, registro de claves públicas) vienen integrados, por lo que hay una configuración mínima necesaria para empezar a explorar.

La compliance es un parámetro de diseño, no una configuración fija. El mismo contrato de pool puede configurarse para brindar soporte a varios tipos distintos de casos de uso o jurisdicciones. Estas extensiones son open-source y se están iterando activamente.

Puedes (1) probar la demo alojada para una revisión rápida, o (2) usar el SDK para desarrollar contra ella. Ambos corren en testnet; mantén todo solo en testnet.

Lo más rápido: la demo alojada

• Abre la app alojada
• Conecta Freighter en Stellar Testnet (obtén XLM de testnet en Stellar Lab y selecciona “Fund account”) y ejecuta un depósito → transferencia privada → retiro. Si la app se comporta mal tras una actualización, borra el almacenamiento local del sitio; el alpha evoluciona rápido
• Observa un solo campo, ext_amount, en cada transacción en un explorador de testnet como stellar.expert, como este ejemplo de abajo.

deposit    ext_amount   +50000000     +5 XLM (public)
transfer   ext_amount    0            amount + recipient private
withdraw   ext_amount   -20000000     -2 XLM (public, to a new address)

La implementación en testnet actualmente ejecuta pools de XLM y EURC.

Desarrolla con el SDK. El SDK web se distribuye como un paquete prebuilt-WASM en npm, así puedes agregar pagos privados a una app sin tocar una toolchain de Rust:

npm i stellar-private-payments@alpha @stellar/freighter-api

SPP distribuye dos SDK: el TS/JS SDK usado aquí, y un Rust SDK para backend o clientes nativos. Una vez configurado el cliente (init de WASM, almacenamiento y un firmante de wallet, todo explicado en el SDK README), todo el ciclo son tres llamadas:

await pool.deposit(50000000n);              // ext_amount +5  · public
await pool.transfer(recipient, 20000000n);  // ext_amount  0  · amount + recipient private
await pool.withdraw(20000000n);             // ext_amount -2  · public

Los montos mostrados arriba están en stroops; es decir, 1 stroop = 0.0000001 XLM.

El SDK gestiona la sincronización histórica mediante un indexador “bootnode” y sincronización de eventos en segundo plano por ti, para que no te topes con los huecos de 7 días de sincronización de ledger que tendría una conexión RPC cruda. El SDK README tiene el ciclo completo funcionando, desde init hasta la firma con Freighter, y es la fuente de verdad a medida que el alpha evoluciona.

La firma es modular: FreighterSigner es el adaptador de Freighter integrado, pero cualquier firmante que implemente la interfaz del SDK funciona, así que no estás atado a una sola wallet.

O sáltate la app por completo: la CLI de spp (la CLI es solo un pequeño adelanto, no es totalmente compatible con todas las funciones). Instalación en una línea:

curl -fsSL https://nethermindeth.github.io/stellar-private-payments/install.sh | sh

Descarga un binario con checksum para tu plataforma, prepara los circuitos y las claves de prueba, y te da el ciclo completo de depositar, transferir y retirar desde la terminal (Stellar CLI con llaves importadas es requerida). Luego ejecuta spp onboard para aceptar el aviso y derivar tus llaves; spp --help muestra el conjunto completo de comandos. Esto es para ti o tu agente: la CLI es una superficie totalmente scriptable, así que si creas con un agente de código, apúntalo al README del repo y a la CLI de spp y deja que ejecute todo el flujo de testnet por ti.

Clona stellar-private-payments y envía issues durante la ventana de testnet. La documentación completa está en Privacy on Stellar.

Damos la bienvenida a socios de diseño y contribuciones de desarrolladores. Si estás creando soluciones de privacidad centradas en cumplimiento en Stellar, eres miembro de una cohorte de SCF, o te uniste a nuestro reciente Stellar Hacks: Real-World ZK hackathon o Stellar Summit São Paulo, comparte en qué estás trabajando en nuestro Developer Discord.

Nos entusiasma contar con Antonio Larriba Investigador en Criptografía en Nethermind, que trabajó en el desarrollo, se una a Alessandro Voto Senior Product Manager en Stellar Development Foundation para conversar sobre Stellar Private Payments y nuestro trabajo con Nethermind para avanzar la privacidad en Stellar.

Conéctate 28 de ago @ 4:00 PM UTC para ver el stream en @BuildOnStellar.

Stellar Private Payments es parte de un stack de privacidad más amplio en Stellar. Para contexto sobre las primitivas que lo hicieron posible, consulta: stellar.org/privacy, la documentación para desarrolladores de Stellar sobre privacidad, Vista previa para desarrolladores: Confidential Tokens en Stellar y la taxonomía en el Apéndice abajo.

Una forma fácil de entender las soluciones de privacidad onchain es preguntar:

¿Qué ve la red y qué permanece privado?

Por qué existen ambas vías. Los pools de privacidad están diseñados para flujos donde las contrapartes necesitan privacidad, como liquidaciones B2B, donaciones. Mientras que Confidential Tokens encajan en flujos con contrapartes conocidas donde el monto necesita privacidad, como nómina, gestión de tesorería. Algunos casos de uso pueden beneficiarse de ambos.

Jerarquía de privacidad por capas de Stellar

Capa de aplicación: contratos inteligentes de Stellar que implementan comportamientos específicos de privacidad. Estos incluyen implementaciones de pools de privacidad como Stellar Private Payments (SPP) y Confidential Tokens.

Capa de verificación: Un verificador onchain es un contrato inteligente que acepta una prueba ZK compacta y confirma su validez sin volver a ejecutar el cómputo original. Los ejemplos incluyen el verificador Groth16 usado por Stellar Private Payments y el verificador UltraHonk de Nethermind usado por el contrato Confidential Token.

Funciones host criptográficas. Integradas en el protocolo de Stellar en la capa base: operaciones de curvas elípticas sobre las curvas BN254 y BLS12-381, y la función hash Poseidon/Poseidon2. Introducidas en las actualizaciones X-Ray (Protocolo 25) y Yardstick (Protocolo 26). Estas primitivas de funciones host permiten una verificación eficiente en recursos directamente onchain, proporcionando mayor garantía de seguridad y descentralización.

Libro mayor base (público). Los contratos de privacidad residen en las capas superiores, con las funciones host criptográficas residiendo en la capa del libro mayor público.