¡La mainnet de Aptos habilitará muy pronto activos 🔒 confidenciales 💸!! a saber, saldos y montos de transacciones encriptados 🔐, 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 en y amplían trabajos anteriores. Encriptamos los saldos en la cadena utilizando Twisted ElGamal, como PGC (). Esto se compone bien con Bulletproofs para demostrar que un saldo encriptado fue debitado correctamente después de un envío/retiro confidencial.

O, como me gusta decir a menudo [y de lo que se ríen en este punto]... "¡Mira mi blog!"

*Característica 1:* A diferencia de PGC y Solana, nuestros cifrados de ElGamal retorcido están _agresivamente fragmentados_ para asegurar una desencriptación súper rápida mientras manejan saldos y montos de ~256 bits. Lo llamamos *ElGamal fragmentado y retorcido.* Para que conste, Aptos solo necesita saldos de 128 bits y montos de 64 bits.

Para Aptos, el fragmentado garantiza que la máxima instancia de logaritmo discreto (DL) que necesita ser resuelta durante la descifrado es de 32 bits, en el peor de los casos (y mucho más pequeña en promedio). => fácilmente resoluble en 2^16 adiciones de curvas elípticas utilizando algoritmos simples como baby-step giant-step (BSGS)👇

*Función 2:* Aceleramos BSGS para nuestra elección de la curva elíptica Ristretto255 a través de compresiones por lotes. También reducimos el tamaño de su tabla precomputada en 4x (=> reduce el tamaño y la latencia del SDK de dapps confidenciales) Llamamos a este nuevo algoritmo *BSGS-k truncado (TBSGS-k).*

He hablado de este algoritmo antes: ...pero no he enfatizado el *por qué*: TBSGS-k es determinista => más simple de implementar y probar. TBSGS-k es solo ~2x más lento (10.6 ms frente a 4.8 ms) que el algoritmo más complejo [BL12], y tiene tablas solo 2x más grandes.

*Función 3:* Cuando la auditoría está habilitada, mantenemos un cifrado comprobablemente correcto del saldo (disponible) de cada usuario bajo la clave de cifrado del auditor (EK). Esto impide que los auditores escaneen las transacciones de los usuarios para reconstruir su saldo. Clave: permite las rotaciones de EK del auditor 👌

*Función 4:* En Aptos, la rotación de la clave de _firma_ del usuario es una característica central de seguridad. Así que: ¡también diseñamos activos confidenciales para soportar la rotación de la clave de *desencriptación* del usuario! Por ahora, las políticas de gestión de claves quedan a cargo de las aplicaciones/billeteras (últimas palabras famosas 🤞).

La buena noticia: ¡Las dapps confidenciales sin clave pueden reutilizar de forma segura su 🌶️ como clave de descifrado! () ==> no se introduce ninguna carga adicional de gestión de claves para tales aplicaciones ==> la forma más fácil de construir una dapp confidencial es como una dapp sin clave; ¡no se necesita [soporte] de billetera!

*Función 5:* Implementar criptografía que asegura los fondos reales de los usuarios es aterrador. Para minimizar errores (🤞), utilizamos una metodología en gran medida pasada por alto para diseñar y componer de manera segura los protocolos Sigma: El *marco de homomorfismo,* que descubrí en el libro de @danboneh 🙏

*Función 6:* La primera implementación de activos confidenciales lista para producción en Move. El código es actualmente privado mientras se somete a una auditoría, pero se publicará pronto. Aquí hay un adelanto de lo simple que puede ser una transferencia confidencial 👇

Además, porque no puedo evitarlo, aquí hay parte de nuestro marco de homomorfismo del protocolo Sigma implementado en Move 😍

*Característica 7:* Especificación criptográfica completa con pruebas de seguridad. (Quizás podamos codificarlo en @leanprover?) Próximamente, con los detalles picantes, en un eprint junto a ti 👇

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

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

3. Solana (): permite cantidades transferidas de 48 bits al dividir el saldo pendiente en un fragmento "alto" de 32 bits y un fragmento "bajo" de 16 bits. Permitimos cantidades mayores utilizando un mayor número de fragmentos y además fragmentando el saldo disponible también.

Por último, pero no menos importante, quiero agradecer 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 🖖 ¡Estén atentos a nuestro artículo conjunto que saldrá pronto!