¡La mainnet de Aptos habilitará 🔒 los activos 💸 confidenciales muy pronto! es decir, saldos cifrados y cantidades 🔐 de transacciones, aunque con direcciones de remitente y destinatario visibles 🌍 públicamente. (Un paso a la vez, amigos...) ¡Así es como funcionan! 🤓👇

Los activos confidenciales de Aptos se basan y amplían trabajos previos. Ciframos balances on-chain usando Twisted ElGamal, como PGC (). Esto se compone bien con Bulletproofs para demostrar que un saldo cifrado se debió correctamente tras un envío/retiro confidencial.

O, como me gusta decir a menudo [y de lo que se burlan de mí a estas alturas]... "¡Mira mi blog!"

*Dote 1:* A diferencia de PGC y Solana, nuestros textos cifrados de Twisted ElGamal son _aggressively-chunked_ para asegurar un descifrado súper rápido mientras gestionan saldos y cantidades de ~256 bits. Lo bautizamos *trozo y retorcido ElGamal.* Por si sirve de algo, Aptos solo necesita saldos de 128 bits y cantidades de 64 bits.

Para Aptos, el chunking garantiza que la instancia máxima de log discreto (DL) que debe resolverse durante el descifrado sea de 32 bits, en el peor de los casos (y mucho menor de media). => fácilmente resoluble en 2^16 sumas de curvas elípticas usando algoritmos simples como el paso gigante paso pequeño (BSGS) 👇

*Dote 2:* Aceleramos la BSGS para nuestra elección de curva elíptica Ristretto255 mediante compresiones en lote. También reducimos el tamaño de su tabla precalculada en 4 veces (=> reducimos el tamaño y la latencia del SDK de las dapps confidenciales) A este nuevo algoritmo lo llamamos *BSGS-k truncado (TBSGS-k).*

He bromeado con este algoritmo antes: ... pero no logró enfatizar el *por qué*: TBSGS-k es determinista = > más sencillo de implementar y probar. TBSGS-k es solo ~2 veces más lento (10,6 ms frente a 4,8 ms) que el algoritmo más complejo [BL12], y tiene solo tablas 2 veces más grandes.

*Hazaña 3:* Cuando la auditoría está habilitada, mantenemos un cifrado demostrablemente correcto del saldo (disponible) de cada usuario bajo la clave de cifrado del auditor (EK). Esto impide que los auditores escaneen los TXN de los usuarios para reconstruir su saldo. Clave: permite rotaciones 👌 de auditores en EK

*Dote 4:* En Aptos, la rotación de la tecla de _signación_ del usuario es una función central de seguridad. Así que: ¡también diseñamos activos confidenciales para soportar la rotación de claves de *descifrado* de los usuarios! Por ahora, las políticas de gestión de claves se dejan a las aplicaciones y carteras (palabras famosas de última 🤞 palabra).

La buena noticia: ¡las dapps confidenciales sin clave pueden reutilizarlas 🌶️ de forma segura como clave de descifrado! () ==> no se introduce ninguna carga adicional de gestión de claves para tales aplicaciones ==> forma más sencilla de crear un dapp confidencial es como un dapp sin llave; ¡No hace falta cartera [soporte]!

*Dote 5:* Implementar cripto(*gráfico*) que asegure fondos reales de usuarios es aterrador. Para minimizar errores (🤞), utilizamos una metodología en gran parte ignorada para diseñar y componer protocolos Sigma de forma segura: El *marco de homomorfismos*, que descubrí en el libro 🙏 de @danboneh

*Dote 6:* La primera implementación de activo confidencial lista para producción en Move. El código está actualmente privado mientras se somete a una auditoría, pero será publicado pronto. Aquí tienes un adelanto de lo sencilla que puede ser 👇 una transferencia confidencial

Además, como no puedo evitarlo, aquí tienes parte de nuestro marco de homomorfismos de protocolos Sigma implementado en Move 😍

*Dote 7:* Especificación criptográfica completa con pruebas de seguridad. (Vaya, quizá podamos programarlo en @leanprover?) Próximamente, con los detalles picantes, en una edición electrónica a tu 👇 lado

Por último, crédito donde se debe: los activos confidenciales de Aptos se basan y amplían ideas introducidas en trabajos 👇 previos 1. Zether (): el problema de "adelantamiento" del modelo de cuenta fija mediante saldos pendientes

2. PGC (): propuso Twisted ElGamal + Bulletproofs como una alternativa más sencilla a las \Sigma-bullets. Esto reduce drásticamente la complejidad de la implementación: ¡solo necesitamos centrarnos en diseñar correctamente nuestros protocolos Sigma! La composición segura se argumenta a continuación 👇

3. Solana (): permitía transferencias de 48 bits dividiendo el saldo pendiente en un fragmento "alto" de 32 bits y un fragmento "bajo" de 16 bits. Permitimos cantidades mayores usando un mayor número de trozos y además dividiendo el saldo disponible.

Por último, pero no menos importante, quiero dar las gracias a @mstrakastrak y a la gente de @distributedlab, que ayudaron a diseñar la versión inicial del protocolo de activos confidenciales e implementarlo en Move y TypeScript 🖖 ¡Estad atentos a nuestro artículo conjunto que saldrá pronto!