Secreto 2.0: Construyendo la próxima generación de privacidad en la Web3

Nuevas soluciones criptográficas, redes complementarias, endurecimiento de enclaves y mucho más. Eche un primer vistazo a Secret 2.0, una evolución masiva de nuestra arquitectura como centro de privacidad para Web3.

¡Hola a la comunidad!

Hoy escribo para hablar del pasado, el presente y el futuro de Secret Network — y para compartir algunos planes que hasta ahora nunca se han compartido.

El ecosistema de Secret siempre ha estado orgulloso de nuestra capacidad para iterar rápidamente y estar a la vanguardia de las tecnologías pragmáticas de preservación de la privacidad que pueden ser desplegadas en la producción. Hace siete años, fuimos el primer equipo en hablar de privacidad para Web3 cuando publiqué mis libros blancos originales (incluyendo “Decentralizing Privacy”, ahora con más de 2.000 citas y el artículo más citado actualmente sobre privacidad en la cadena de bloques). Hace más de dos años, Secret se convirtió en el primer contrato inteligente L1 que preserva la privacidad, lo que sigue siendo el caso hoy en día.

Pero a medida que Secret Network crece, junto con la propia Web3, ha llegado el momento de pensar en mayor medida en nuestra visión de la privacidad y en cómo asegurarnos de estar siempre a la vanguardia tanto de la investigación como del desarrollo. No queremos quedarnos nunca estancados en un máximo local, sino que queremos ser siempre el líder del mercado en soluciones de privacidad de Web3 que estén activas en la producción. Siempre queremos impulsar nuestras soluciones para que sean más seguras, más eficaces, más rápidas y de menor coste, especialmente a medida que aumenta su adopción.

Nos referimos a todo el desarrollo hasta este punto como “Secreto 1.0”: una blockchain de capa 1 viva y un ecosistema relativamente maduro de aplicaciones de preservación de la privacidad en producción. Hoy hablaremos de “Secret 2.0”: hacia dónde llevan el ecosistema las nuevas investigaciones y desarrollos.

Una publicación completa de la visión colectiva de Secret 2.0 requeriría un whitepaper en profundidad que incluyera todo, desde las minucias técnicas hasta la económica. Hoy no es esa publicación. Pero en esta entrada, me gustaría compartir un par de piezas críticas de una hoja de ruta para elevar las soluciones de privacidad de Secret a otro nivel:

1. La creación de una red complementaria: un umbral de cifrado totalmente homomórfico (FHE) de capa 1 que, junto con los enclaves, proporciona la mejor solución de privacidad de su clase.
2. Endurecimiento de SGX (y otros enclaves compatibles) mediante técnicas criptográficas y de ingeniería práctica.

Con estas mejoras, el futuro de Secret se parece más a una brillante constelación de soluciones de privacidad interconectadas que a una única estrella. Echemos un vistazo a las dos vías estratégicas mencionadas y a cómo ayudarán a definir a Secret como el centro de la privacidad para toda la Web3.

Al final de este artículo, también incluiremos una llamada a la acción para los investigadores, desarrolladores y socios interesados en contribuir a Secret 2.0. Si eres un investigador, desarrollador o equipo independiente que está interesado en unirse a este esfuerzo, ponte en contacto con SCRT Labs a través del correo electrónico: info@scrtlabs.com

Cifrado totalmente homomórfico por umbral para contratos secretos

Siempre hemos afirmado que la misión de Secret es aportar las soluciones de privacidad más pragmáticas y prácticas a los sistemas de producción. La privacidad es demasiado importante como para debatirla únicamente en un entorno académico: los usuarios la necesitan hoy en día. Sin embargo, seguimos muy de cerca todos los nuevos avances académicos para entender cuándo y cómo las nuevas soluciones podrían desplegarse en producción en beneficio de desarrolladores y usuarios. La seguridad es un espacio en constante evolución.

Ya hemos comentado en el pasado que los enclaves seguros eran (y realmente siguen siendo) la única tecnología actualmente lista para ser utilizada en una red de contratos inteligentes generalizable. Los enclaves proporcionan un rendimiento más rápido a un coste menor en más casos de uso. Por eso nos centramos en su uso en Secret 1.0.

Sin embargo, siempre hemos considerado cómo la combinación de múltiples tecnologías podría conducir a mejores soluciones listas para la producción. Gracias a los recientes avances, ahora estamos explorando el cifrado totalmente homomórfico (FHE) como una opción seria para fortalecer a Secret como centro de privacidad.

Está previsto que una nueva red complementaria basada en FHE (cuyo nombre está por revelar) se parezca mucho a Secret, y actualmente estamos trabajando en una forma interesante de interconectar las dos de forma cruzada. Pero para el propósito de esta entrada de blog, me gustaría centrarme en el diseño técnico de dicha cadena y en cómo puede proporcionar la solución más segura para resolver el problema de la privacidad.

La red aprovechará el Cifrado Totalmente Homomórfico para la privacidad, que es un esquema que permite calcular sobre datos cifrados. Esencialmente, mantiene la invariante de:

Los esquemas FHE han mejorado el rendimiento a pasos agigantados en los últimos años, y la tendencia parece continuar. Mediante el uso de GPU, FPGA y, eventualmente, ASIC, podemos esperar un aumento de 1.000 a 10.000 veces en los próximos años. Los avances son prometedores y ahora hay buenas razones para creer que FHE puede llegar a ser lo suficientemente escalable en un plazo bastante corto.

Pero hay un problema. El propio FHE sólo puede funcionar con una sola clave, así que, ¿cómo podemos hacer frente a un entorno multiusuario como es el caso de las cadenas de bloques? Tenemos que utilizar esencialmente una variante de FHE de computación multipartita (MPC) llamada Threshold FHE. Como su nombre indica, Threshold FHE permite que cada servidor ejecute cualquier cálculo sobre los datos encriptados, pero para descifrar el resultado, un determinado umbral de nodos debe trabajar conjuntamente para descifrar.

Entonces, ¿cómo encaja esto en nuestra red de acompañamiento? Esencialmente, con un esquema Threshold FHE adecuado, podemos hacer que los validadores compartan la clave secreta de encriptación entre ellos. Esto puede lograrse fácilmente con un simple protocolo DKG que es altamente eficiente. Utilizando la compartición proactiva de secretos móviles, podemos esencialmente mover las acciones de los validadores que se van a los que se unen. La parte “proactiva” aseguraría que cualquier atacante no pueda corromper lentamente a los validadores a lo largo del tiempo, ya que requiere que los validadores refresquen sus acciones de la clave cada cierta cantidad de bloques.

Con esta configuración, enviar una transacción de contrato inteligente a la red es bastante trivial:

1. El usuario envía una transacción llamando a una función en un contrato específico, mientras encripta todos sus datos utilizando la clave pública de la clave de red compartida.
2. Todos los validadores ejecutan el consenso como de costumbre, mientras calculan sobre los datos encriptados. Esto es básicamente similar a cómo funciona Secret hoy en día, excepto que el cálculo se realiza directamente sobre los datos encriptados sin descifrarlos en un enclave.
3. Usando este esquema podemos lograr la privacidad de entrada, estado y salida al igual que en Secret hoy en día. (Para la privacidad de la salida, todos los validadores deben ejecutar un protocolo de cambio de clave que hace un reencriptado proxy de umbral para cambiar la salida para que sea descifrable con una clave que sólo conoce el usuario).

Una nota importante que hay que mencionar es que cada validador obtendrá una parte de la clave de descifrado en función de su apuesta. Se necesitaría el 67% de la participación para descifrar la red. Esta cifra está en línea con el número de votos para aprobar un bloque, así que tiene sentido.

Un problema de este diseño es que los validadores pueden coludirse, y la colusión es trivial e indetectable (escribir unas pocas líneas de código que permitan a los validadores intercambiar las claves secretas compartidas fuera de la cadena). Por esta razón, creemos que para este trabajo necesitaremos combinar estas técnicas criptográficas con SGX o un TEE similar (idealmente múltiples TEEs que utilicen múltiples arquitecturas). Al hacerlo, aumentamos la barrera de los ataques: ahora es necesario conseguir que todos los validadores se confabulen, lo que resulta extremadamente improbable cuando se utilizan TEEs.

Sin embargo, también es importante señalar que ejecutar FHE dentro de un enclave es probablemente una mala idea. Como se ha mencionado, el escalado de FHE dependerá en sí mismo del soporte de GPUs, FPGAs o ASICs, lo cual no es compatible hoy en día con los enclaves. Por suerte, debería ser fácil ver que sólo necesitamos realmente la clave de descifrado del umbral en caso de un cambio de clave o un descifrado del umbral. Todo el cómputo encriptado real puede ocurrir fuera del enclave, lo que ayudaría mucho al rendimiento. Además, limitar los propios enclaves para que se centren en almacenar una clave compartida y ejecutar un protocolo específico de cambio de clave/descifrado de umbral significa que sería mucho más fácil proteger ese enclave de cualquier posible ataque.

Endurecimiento de SGX y otros Enclaves

La introducción de soluciones criptográficas como FHE en nuestra constelación de privacidad mejorará significativamente la oferta de Secret para desarrolladores y usuarios. Sin embargo, hay mucho más que podemos hacer mientras tanto para reforzar nuestra red actual, así como para mejorar su futura flexibilidad. La mayoría de estas ideas también contemplan la combinación de criptografía más avanzada con SGX, de forma que se aprovechen las ventajas de los enclaves seguros pero sin depender únicamente de ellos.

Umbralización de la llave maestra

Hace muy poco escribí un post en el foro que describía cómo podemos adaptar un artículo reciente de Momeni et al., que aprovecha el Cifrado Basado en la Identidad (IBE) con la compartición de secretos para distribuir la clave maestra de Secret, que es la principal fuente de entropía utilizada para generar claves de cifrado para las transacciones de los usuarios, los cifrados de estado, la aleatoriedad en la cadena, etc.

La idea propuesta divide la clave maestra actual, que está presente en todos los enclaves (y, por tanto, bastaría con romper un solo enclave para descifrar todos los datos), en partes de la clave, de forma que se necesitarían las partes del 67% de los validadores para poder conocer la clave. Dado que todas estas acciones también viven en enclaves, se mantiene el mismo argumento de la cadena Threshold FHE anterior: necesitar romper los enclaves de la mayoría de la red es probablemente poco práctico en cualquier situación.

La clave maestra secreta compartida se utilizará entonces para generar una clave derivada para cada bloque. Lo interesante es que los usuarios pueden generar a priori y de forma independiente la correspondiente clave pública para cada bloque, con lo que el cifrado de las transacciones por parte del cliente no es interactivo, como ocurre actualmente. Además, todos los validadores pueden generar su parte derivada de la clave secreta de forma independiente también, y para cada bloque adjuntarla como parte del mecanismo de consenso. Esto significa que los enclaves aprenden la clave de un bloque específico justo a tiempo para ejecutar los cálculos, ¡pero nunca aprenden la clave maestra!

Podemos utilizar la misma técnica móvil de compartición proactiva de secretos de la cadena FHE para asegurarnos de que las claves maestras compartidas se actualizan periódicamente y se trasladan de los validadores antiguos a los nuevos, para mejorar tanto la seguridad como la disponibilidad.

¿Secreto de avance?

El esquema anterior utiliza esencialmente el cifrado homomórfico y el cálculo multipartito (MPC) para evitar una posible fuga de la clave maestra incluso en una catástrofe de SGX. Asimismo, protege mejor contra la colusión, a la que son vulnerables todas las técnicas de MPC, al mantener todas sus claves compartidas en su enclave.

Esto es estupendo, pero aún queda un gran reto por resolver. Los validadores aprenden la clave de un bloque una vez cada bloque. Si un adversario se sienta en un enclave comprometido, puede recoger lentamente las claves y descifrar los bloques. Esto tiene un alcance limitado si se asume que hay una ventana de tiempo limitada entre la posibilidad de comprometer un enclave y su reparación. Con el paso de los años, y a medida que los enclaves se vayan probando en la batalla, esto debería ser más raro e improbable, pero sigue siendo una forma de ataque. Tal vez sea más preocupante que un nuevo validador que esté empezando y desee procesar todo el estado histórico pueda tomar instantáneamente un enclave comprometido y aprender toda la historia.

Esta preocupación debe abordarse con alguna forma de secreto hacia adelante para las cadenas de bloques que preservan la privacidad y es probablemente relevante si se utilizan enclaves de soluciones criptográficas puras que necesitan almacenar claves en la red. El secreto hacia adelante significa esencialmente que cualquier clave específica que se filtre no debería revelar más que un poco de información (por ejemplo, una sola transacción o un bloque de datos). Esto se consigue hasta cierto punto con mi propuesta anterior, pero también debería haber un mecanismo que limite la capacidad de recuperar todas las claves de una sola vez.

Este es un tema de investigación abierto que estamos estudiando e invitamos a otros investigadores a colaborar con nosotros. También tiene potencialmente muchas otras implicaciones.

Two-party Computations

Secret 1.0 tiene una propiedad muy interesante y peculiar: puede almacenar y operar con datos privados y, al mismo tiempo, como cualquier blockchain, asegurarse de que siempre está ejecutando el código del contrato correctamente. Además, como cualquier otra blockchain, siempre está en línea.

Esto presenta un tipo de aplicaciones realmente interesantes, en particular para los datos extremadamente sensibles como las claves criptográficas y de billetera, las contraseñas y las semillas, en las que tal vez no queramos confiar plenamente en SGX por sí solo, pero en una línea similar, los propios usuarios no querrían confiar en sí mismos para gestionar adecuadamente esas claves.

El caso de uso actual más interesante y útil que vemos para esto es el de los monederos de umbral imparable, pero esto debería servir sólo como ejemplo. Estos monederos esencialmente dividen la clave del monedero entre un usuario y Secret — cada uno obtiene una parte. En Secret, un usuario puede definir una política de acceso, de tal manera que si su clave es cada vez comprometida, la cadena notaría un comportamiento sospechoso (por ejemplo, alguien tratando de drenar su cartera) y lo bloquearía. Por otro lado, es bastante razonable suponer que ningún atacante podrá comprometer tanto la parte almacenada en la red como la parte del monedero del usuario, especialmente si continuamos utilizando técnicas como la compartición proactiva de secretos que refrescan las partes cada cierto tiempo.

Para habilitar esta técnica, tendríamos que añadir soporte y construir varios bloques de construcción en Secret, como el cifrado aditivamente homomórfico y los protocolos de firma de umbral. Tendremos que adaptarlos para que funcionen sin ser compilados en WASM por cuestiones de rendimiento/coste de gas (de forma similar a lo que hizo Ethereum en el pasado con la verificación en la cadena de ciertas pruebas de conocimiento cero). Actualmente se está planeando un piloto de este tipo con un socio de diseño.

Esto debería ilustrar una clase mucho mayor de cálculos de dos partes, donde el material sensible de un usuario se divide entre el propio usuario y Secret.

¿Ahora qué?

Aquí reafirmaré lo que siempre ha sido parte de nuestra misión como Secret Network: llevar al mercado soluciones de privacidad pragmáticas para que puedan ser utilizadas en producción por millones de usuarios globales.

El ecosistema de Secret -desde sus desarrolladores principales hasta sus validadores, pasando por sus dApps y sus apasionados usuarios- ha demostrado que haremos todo lo necesario para garantizar que nuestra visión de un futuro más seguro en la Web3 se haga realidad. Eso ha significado construir y utilizar aplicaciones que están a la vanguardia de nuestra industria durante los últimos años. Ahora le pedimos que se una a nosotros para fortalecer nuestra red desde su primera iteración hasta su siguiente forma más potente: una constelación de soluciones de privacidad interconectadas que hace que la base colectiva sea cada vez más fuerte.

Hay muchos otros temas que podríamos haber tocado en este post, incluyendo el escalamiento vertical a través de rollups, el escalamiento horizontal a través de IBC, y mucho más. Esto es sólo un primer vistazo a Secret 2.0, que será un esfuerzo muy complejo que incluye un importante esfuerzo comunitario.

En la actualidad tenemos docenas de dApps privadas por defecto que aprovechan Secret Network; en unos años, nuestro objetivo es tener miles. Hoy tenemos 250.000 cuentas en Secret; nuestro objetivo es añadir muchos millones más. Combinando estas mejoras técnicas con un enfoque agresivo para el crecimiento de desarrolladores y usuarios, podemos asegurar que cada usuario de Web3 tenga acceso a soluciones de privacidad sólidas.

Una Internet más descentralizada requiere que la privacidad sea realmente poderosa. Del mismo modo, las soluciones de privacidad requerirán la descentralización para ser sostenibles. Secret Network es el lugar donde la descentralización y la privacidad se cruzan, proporcionando la base adecuada para los usuarios ahora y en el futuro.

Póngase en contacto con nosotros

Gran parte de lo que se propone más arriba es ya un área activa de investigación y desarrollo, pero buscamos constantemente los mejores socios mientras seguimos persiguiendo este objetivo de adopción global. Si usted es un investigador independiente, un desarrollador o un equipo que está interesado en unirse a este esfuerzo o en una empresa conjunta, póngase en contacto con SCRT Labs a través del correo electrónico: info@scrtlabs.com