)

Ideas centrales:

1. FHE promete ser el "Santo Grial de la criptografía", sin embargo, existen muchas preocupaciones sobre el rendimiento, la experiencia de los desarrolladores y la seguridad que limitan su adopción actual.

2. Como se muestra en el gráfico anterior, será necesario utilizar FHE junto con ZKP y MPC para construir un sistema estatal compartido verdaderamente confidencial y seguro.

3.FHE está evolucionando rápidamente; El desarrollo de nuevos compiladores, bibliotecas, hardware, etc. Sin mencionar que FHE se beneficia enormemente de la I+D de las empresas Web2 (Intel, Google, DARPA, etc.).

4. A medida que la FHE y el ecosistema que la rodea maduren, esperamos que la “FHE verificable” se convierta en el estándar. Las aplicaciones FHE pueden optar por subcontratar el cálculo y la verificación a coprocesadores de FHE.

5. Una limitación fundamental de FHE en cadena es "¿quién tiene la clave de descifrado?" El descifrado de umbral y MPC ofrecen soluciones, sin embargo, generalmente están sujetos a una compensación entre rendimiento y seguridad.

Introducción

La naturaleza transparente de las cadenas de bloques es un arma de doble filo; Si bien su apertura y observabilidad son hermosas, es un obstáculo fundamental para la adopción empresarial.

La privacidad en cadena ha sido uno de los problemas más desafiantes en criptografía durante casi una década. Aunque hay muchos equipos que crean sistemas basados en ZK para lograr la privacidad en cadena; no pueden admitir un estado cifrado compartido. ¿Por qué? La respuesta corta es porque estos programas son función de una serie de ZKP y, como tal, es imposible que alguien aplique una lógica arbitraria al estado actual. ¿Qué quiere decir esto? Básicamente, no podemos crear aplicaciones estatales compartidas confidenciales (piense en Uniswap privado) utilizando solo ZKP.

Sin embargo, avances recientes han demostrado que la combinación de ZKP con cifrado totalmente homomórfico (FHE) podría lograr DeFi confidencial y totalmente generalizable. ¿Cómo? FHE es un campo floreciente de la criptografía que permite el cálculo arbitrario sobre datos cifrados (suena loco, ¿verdad?). Como se muestra en el gráfico anterior, los ZKP pueden demostrar la integridad de las entradas y los cálculos del usuario, y FHE puede procesar el cálculo en sí.

Si bien FHE promete ser el "Santo Grial de la criptografía", intentamos proporcionar un análisis objetivo del campo y sus diversos desafíos y posibles soluciones. Cubrimos los siguientes temas FHE en cadena:

• Esquemas, bibliotecas y compiladores FHE
• Descifrado de umbral seguro
• ZKP para entradas de usuario + fiesta informática
• Capa DA programable y escalable
• Ferretería FHE

Esquemas, bibliotecas y compiladores FHE

Desafío: esquemas, bibliotecas y compiladores FHE incipientes

El cuello de botella fundamental de FHE en cadena radica en su infraestructura/herramientas de desarrollador rezagadas. A diferencia de los ZKP o MPC, FHE solo existe desde 2009 y, por lo tanto, tuvo un cronograma mucho más corto para madurar.

Las principales limitaciones de FHE DevEx son:

• Un lenguaje de interfaz de usuario fácil de usar para que los desarrolladores codifiquen sin mucho conocimiento de la criptografía de fondo.
• Un compilador FHE completamente funcional que puede manejar todo el trabajo sucio. (Selección de parámetros, optimización SIMD para BGV/BFV y optimización paralela)
• Los esquemas FHE existentes (particularmente TFHE) son alrededor de 1000 veces más lentos en comparación con el cálculo simple.

Para comprender realmente las complejidades de la integración de FHE, repasemos el recorrido del desarrollador:

El primer paso para integrar FHE en su aplicación es elegir un esquema FHE a utilizar. El siguiente cuadro explica los esquemas principales:

Como se muestra en la tabla anterior, los circuitos booleanos como FHEW y TFHE tienen el arranque más rápido y pueden evitar un complicado procedimiento de selección de parámetros bastante complejo, y podrían usarse en cálculos arbitrarios/genéricos, pero son relativamente lentos; Si bien BGV/BFV podría ser adecuado para DeFi general, ya que son más eficientes en cálculos aritméticos de alta precisión, los desarrolladores deben conocer la profundidad del circuito de antemano para configurar todos los parámetros del esquema. En el otro extremo del espectro, CKKS admite la multiplicación homomórfica donde se permiten errores de precisión, lo que la hace óptima para casos de uso no precisos como ML.

Como desarrollador, debe elegir una solución FHE con mucho cuidado, ya que afectará todas las demás decisiones de diseño y el rendimiento futuro. Además, existen varios parámetros clave que son cruciales para configurar correctamente el esquema FHE, como la elección del tamaño del módulo y la función del grado del polinomio.

Pasando a las bibliotecas, las características y capacidades de las bibliotecas FHE populares se pueden ver en la siguiente tabla:

Pero las bibliotecas también tienen diferentes relaciones con los esquemas y compiladores, como se muestra a continuación:

Después de seleccionar la solución FHE, los desarrolladores deben establecer parámetros. La selección adecuada de parámetros tendrá un gran impacto en el desempeño del esquema FHE. Lo que es más difícil, esto requiere cierta comprensión del álgebra abstracta, operaciones específicas de FHE, como la relinealización y la conmutación de analógico a digital, y circuitos aritméticos o binarios. Finalmente, para una selección eficaz de parámetros, se requiere una comprensión conceptual de cómo afectan al esquema FHE.

En este punto, los desarrolladores pueden preguntar:

¿Qué tamaño debe tener mi espacio de texto sin formato? ¿Qué magnitud de textos cifrados son aceptables? ¿Dónde puedo paralelizar el cálculo? Y muchos más…

Además, aunque FHE puede admitir cálculos arbitrarios, los desarrolladores deben cambiar su forma de pensar al escribir programas FHE. Por ejemplo, no se puede escribir una rama (if-else) dependiendo de una variable en el programa, porque los programas no pueden comparar directamente las variables como si fueran datos simples. En cambio, los desarrolladores necesitan cambiar su código de ramas a algún tipo de cálculo que pueda incorporar las condiciones de todas las ramas. De manera similar, esto evita que los desarrolladores escriban bucles en su código.

En resumen, para un desarrollador no iniciado en FHE, es casi imposible integrar FHE en su aplicación. Se necesitarán importantes herramientas de desarrollo/infraestructura para abstraer las complejidades que presenta FHE.

Solución:

1. Compiladores FHE específicos de Web3

Si bien ya existen compiladores FHE creados por empresas como Google y Microsoft, son:

• No está diseñado teniendo en cuenta el rendimiento, agregando una sobrecarga de 1000 veces en comparación con los circuitos de escritura directamente
• Optimizado para CKKS (también conocido como ML) y no tan beneficioso para BFV/BGV necesario para DeFi
• No construido para Web3. No admite compatibilidad con esquemas ZKP, encadenamiento de programas, etc.

Eso es hasta el compilador Sunscreen FHE. Es un compilador nativo de Web3 que ofrece uno de los mejores rendimientos para operaciones aritméticas (piense en DeFi) sin aceleradores de hardware. Como se analizó anteriormente, la selección de parámetros es posiblemente la parte más difícil de implementar un esquema FHE; Sunscreen no solo tiene selección automática de parámetros, sino también codificación de datos, selección de claves, implementa relinealización y conmutación de módulos, configura los circuitos e implementa operaciones de estilo SIMD.

A medida que avanzamos hacia el futuro, esperamos ver más optimizaciones no solo en el compilador Sunscreen, sino también en otros equipos que crean sus propias implementaciones que admiten otros lenguajes de alto nivel.

1. Nueva biblioteca FHE

Mientras los investigadores siguen explorando nuevos esquemas potentes, las bibliotecas FHE pueden permitir que más desarrolladores integren FHE.

Tomemos como ejemplo los contratos inteligentes FHE. Aunque puede resultar difícil elegir entre diferentes bibliotecas FHE, se vuelve más fácil cuando hablamos de FHE en cadena porque solo hay unos pocos lenguajes de programación dominantes en Web3.

Por ejemplo, fhEVM de Zama integra la biblioteca de código abierto TFHE-rs de Zama en un EVM típico, exponiendo operaciones homomórficas como contratos precompilados. Permitir de manera efectiva a los desarrolladores utilizar datos cifrados en sus contratos, sin ningún cambio en las herramientas de compilación.

Para otros escenarios específicos, es posible que se requiera alguna otra infraestructura. Por ejemplo, la biblioteca TFHE escrita en C++ no se mantiene tan bien como la versión Rust. Aunque TFHE-rs puede admitir exportaciones para C/C++, si los desarrolladores de C++ desean una mejor compatibilidad y rendimiento, deben escribir su propia versión de la biblioteca TFHE.

Finalmente, una razón fundamental de la falta de infraestructura FHE en el mercado es que carecemos de formas eficientes de construir FHE-RAM. Una posible solución es trabajar en un FHE-EVM sin ciertos códigos de operación.

Descifrado de umbral seguro

Desafío: descifrado de umbral centralizado/no seguro

Todo sistema de estado compartido y confidencial se basa en una clave de cifrado/descifrado. No se puede confiar en ninguna parte, por lo que la clave de descifrado se divide entre los participantes de la red.

Uno de los aspectos más desafiantes de FHE (Umbral FHE) en cadena es la creación de un protocolo de descifrado de umbral seguro y eficaz. Hay dos cuellos de botella principales: (1) el cálculo basado en FHE introduce una sobrecarga significativa, por lo que requiere nodos de alto rendimiento, lo que inherentemente reduce el tamaño potencial del conjunto de validadores (2) A medida que aumenta el número de nodos que participan en el protocolo de descifrado, aumenta la latencia.

Al menos por ahora, los protocolos FHE dependen de una mayoría honesta entre los validadores; sin embargo, como se indicó anteriormente, Threshold FHE implica un conjunto de validadores más pequeño y, por lo tanto, una mayor probabilidad de colusión y comportamiento malicioso.

¿Qué pasa si los nodos umbral se confabulan? Podrían eludir el protocolo y básicamente descifrar cualquier cosa, desde las entradas del usuario hasta cualquier dato en cadena. Además, es importante tener en cuenta que el protocolo de descifrado puede ocurrir de manera indetectable en los sistemas actuales (también conocido como "ataque silencioso").

Solución: descifrado de umbral mejorado o MPC dinámico

Existen algunas formas de abordar las deficiencias del descifrado por umbral. (1) Habilite un umbral n/2 que haría más difícil la colusión (2) Ejecute el protocolo de descifrado de umbral dentro de un HSM (3) Utilice una red de descifrado de umbral basada en TEE controlada por una cadena descentralizada para la autenticación que permita la dinámica gestión de claves.

En lugar de aprovechar el descifrado por umbral, es posible utilizar MPC. Un ejemplo de un protocolo MPC que podría usarse en FHE en cadena incluye el nuevo 2PC-MPC de Odsy, el primer algoritmo MPC no colusorio y masivamente descentralizado.

Un enfoque diferente podría ser utilizar únicamente la clave pública del usuario para cifrar los datos. Luego, los validadores procesan las operaciones homomórficas y los propios usuarios pueden descifrar el resultado si es necesario. Si bien es factible solo para casos de uso específicos, podríamos evitar por completo el supuesto del umbral.

En resumen, FHE en cadena necesita una implementación MPC eficiente que: (1) Funciona incluso cuando hay actores maliciosos (2) Introduce una latencia mínima (3) Permite la entrada flexible/sin permiso de nodos.

Prueba de conocimiento cero (ZKP) para la entrada del usuario y la parte informática

Desafío: Verificabilidad de las entradas del usuario + Computación:

En web2, cuando solicitamos que se realice una tarea computacional, confiamos completamente en que una empresa determinada ejecutará la tarea exactamente como prometieron detrás de escena. En web3, el modelo está completamente invertido; En lugar de confiar en la reputación de una empresa y simplemente confiar en que actuará con honestidad, ahora operamos en un entorno sin confianza, lo que significa que los usuarios no deberían tener que confiar en nadie.

Si bien FHE permite el procesamiento de datos cifrados, no puede verificar la exactitud de las entradas del usuario ni de los cálculos. Sin la capacidad de verificar cualquiera de las dos cosas, FHE apenas es útil en el contexto de blockchain.

Solución: ZKP para entradas de usuario + grupo de informática:

Mientras que FHE permite a cualquiera realizar cálculos arbitrarios sobre datos cifrados, los ZKP permiten demostrar que algo es cierto sin revelar la información subyacente. Entonces, ¿cómo se relacionan?

Hay tres formas clave en que FHE y ZKP encajan:

1. El usuario debe enviar una prueba de que el texto cifrado de entrada está bien formado. Lo que significa que el texto cifrado cumple con los requisitos del esquema de cifrado y no son solo cadenas de datos arbitrarias.
2. El usuario debe presentar una prueba de que el texto sin formato ingresado satisface las condiciones de una aplicación determinada. Ex. monto_saldo > monto_transferencia
3. El nodo validador (también conocido como parte informática) debe demostrar que ha ejecutado correctamente el cálculo FHE. Esto se conoce como “FHE verificable” y puede verse como análogo a los ZKP necesarios para los rollups.

Para explorar más a fondo las aplicaciones de ZKP:

1. ZKP de texto cifrado

FHE se basa en criptografía basada en celosías, lo que significa que la construcción de la primitiva criptográfica implica celosías, que son seguras PQ (post-cuánticas). Por el contrario, los ZKP populares como SNARKS, STARKS y Bulletproofs no dependen de la criptografía basada en celosía.

Para demostrar que el texto cifrado FHE del usuario está bien formado, debemos demostrar que satisface alguna ecuación matricial-vectorial con entradas de anillos y que los valores numéricos de estos elementos son pequeños. Esencialmente, necesitamos un sistema de prueba de verificación en cadena rentable diseñado para manejar relaciones basadas en celosías, que es un área de investigación abierta.

1. ZKP de entrada de texto sin formato

Además de demostrar que el texto cifrado está bien formado, el usuario debe demostrar que el texto sin formato ingresado satisface los requisitos de la aplicación. Afortunadamente, a diferencia del paso anterior, podemos utilizar SNARK generales para demostrar la validez de las entradas de los usuarios, lo que permite a los desarrolladores hacer uso de los esquemas, bibliotecas e infraestructura ZKP existentes.

Sin embargo, el desafío es que necesitamos "conectar" los dos sistemas de prueba. Conéctese como necesitamos asegurarnos de que el usuario haya utilizado la misma entrada para ambos sistemas de prueba; de lo contrario, un usuario malintencionado podría engañar al protocolo. Una vez más, se trata de una hazaña criptográfica increíblemente difícil y un área abierta para investigaciones iniciales.

Sunscreen también ha sentado las bases con su compilador ZKP que ofrece soporte para Bulletproofs ya que se conecta más fácilmente con SDLP. Se están realizando desarrollos futuros para "vincular" el compilador FHE y ZKP.

Mind Network ha sido pionero en la integración de ZKP para garantizar entradas y salidas de confianza cero además de aprovechar FHE para una computación segura.

1. ZKP de cálculo correcto

La ejecución de FHE en hardware existente es extremadamente ineficiente y costosa. Como hemos visto antes la dinámica del trilema de la escalabilidad, las redes con mayores requisitos de recursos de nodo no pueden escalar a un nivel suficiente de descentralización. Una posible solución podría ser un proceso denominado "FHE verificable", un proceso en el que la parte informática (validador) envía un ZKP para demostrar la ejecución honesta de las transacciones.

Un proyecto llamado SherLOCKED puede mostrar un prototipo inicial de FHE verificable. Básicamente, el cálculo de FHE se descarga a Bonsai de Risc ZERO, que procesa el cálculo a través de los datos cifrados fuera de la cadena y devuelve el resultado con un ZKP y actualiza el estado en la cadena.

Un ejemplo reciente de cómo aprovechar un coprocesador FHE se puede ver en la demostración de subasta en cadena de Aztec. Como cubrimos anteriormente, las cadenas FHE existentes cifran todo el estado con una clave de umbral, lo que significa que el sistema es tan fuerte como su comité de umbral. Por el contrario, en Aztec, los usuarios poseen sus propios datos y, por lo tanto, no están sujetos a un supuesto de seguridad umbral.

Por último, es importante mencionar dónde un desarrollador puede crear una aplicación FHE en primer lugar. Los desarrolladores pueden crear sus aplicaciones en una L1 con tecnología FHE, en un paquete acumulativo de FHE o en cualquier cadena EVM y aprovechar un coprocesador FHE. Cada diseño viene con su propio conjunto de compensaciones, sin embargo, nos inclinamos más hacia paquetes acumulativos de FHE bien diseñados (pionerados por Fhenix) o coprocesadores FHE, ya que heredan la seguridad de Ethereum, entre otros beneficios.

Hasta hace poco, lograr pruebas de fraude en datos cifrados FHE era complejo, pero recientemente el equipo de Fhenix.io demostró cómo lograr pruebas de fraude utilizando la pila Arbitrum Nitro junto con la compilación lógica FHE en WebAssembly.

Capa de disponibilidad de datos (DA) de FHE

Desafío: falta de personalización y rendimiento

Si bien el almacenamiento se ha mercantilizado en web2, no ocurre lo mismo en Web3. Dado que FHE mantiene una gran ampliación de datos de 10,000x+, necesitamos descubrir dónde almacenar grandes textos cifrados de FHE. Si cada operador de nodo en una capa DA determinada descargara y almacenara los datos de cada cadena FHE, solo los operadores institucionales podrían mantenerse al día con la demanda, arriesgándose a la centralización.

En cuanto al rendimiento, Celestia alcanza un máximo de 6,7 MB/s; si queremos ejecutar cualquier formato FHEML, necesitaríamos fácilmente n GB+/seg. Según datos recientes compartidos por 1k(x), las capas DA existentes no pueden admitir FHE debido a decisiones de diseño que limitan el rendimiento (intencionalmente).

Solución: escalado horizontal + personalización

Necesitamos una capa DA que pueda soportar la escalabilidad horizontal. Las arquitecturas DA existentes propagan todos los datos a cada nodo de la red, lo que supone una limitación importante para la escalabilidad. Por el contrario, con la escalabilidad horizontal, a medida que más nodos DA ingresan al sistema, cada nodo almacena una enésima parte de los datos, lo que mejora el rendimiento y el costo a medida que hay más espacio de bloques disponible.

Por otra parte, dado el tamaño sustancial de los datos asociados con FHE, tendría sentido ofrecer a los desarrolladores un mayor nivel de personalización en torno a los umbrales de codificación de borrado. es decir ¿Con qué cantidad del sistema DA se siente cómodo con una garantía? Ya sea ponderación basada en participación o ponderación basada en descentralización.

La arquitectura de EigenDA sirve como base de cómo podría verse una capa DA para FHE. Sus propiedades de escalamiento horizontal, reducción de costos estructurales, desacoplamiento de DA y consenso, etc., todo da paso a un nivel de escalabilidad que algún día podría respaldar a FHE.

Por último, una idea de alto nivel podría ser crear ranuras de almacenamiento optimizadas para almacenar textos cifrados FHE, ya que los textos cifrados siguen un esquema de codificación particular, por lo que tener ranuras de almacenamiento optimizadas podría ayudar con un uso eficiente del almacenamiento y una recuperación más rápida.

Hardware de cifrado totalmente homomórfico (FHE)

Desafío: hardware FHE de bajo rendimiento

En la promoción de aplicaciones de cifrado totalmente homomórfico (FHE) en cadena, un problema importante es la importante latencia debida a la sobrecarga computacional, lo que hace que ejecutar FHE sea poco práctico en cualquier hardware de procesamiento estándar. Esta limitación surge de la gran cantidad de interacción con la memoria debido a la gran cantidad de datos que el procesador necesita procesar. Además de las interacciones de la memoria, los cálculos polinomiales complejos y las operaciones de mantenimiento de texto cifrado que consumen mucho tiempo también generan muchos gastos generales.

Para comprender mejor el estado de los aceleradores FHE, necesitamos descubrir el espacio de diseño: aceleradores FHE de aplicación específica versus aceleradores FHE generalizables.

El quid de la complejidad computacional y el diseño de hardware para FHE siempre está relacionado con la cantidad de multiplicaciones necesarias para una aplicación determinada, lo que se conoce como "profundidad de operación homomórfica". En el caso específico de la aplicación, la profundidad es conocida, por lo que los parámetros del sistema y el cálculo relacionado son fijos. Por lo tanto, el diseño de hardware para este caso de aplicación específica será más fácil y generalmente se puede optimizar para obtener un mejor rendimiento que el diseño de acelerador generalizable. En el caso general, donde se requiere que FHE admita un número arbitrario de multiplicaciones, se necesita arranque para eliminar parte del ruido acumulado en las operaciones homomórficas. El arranque es costoso y requiere considerables recursos de hardware, incluida la memoria en el chip, el ancho de banda de la memoria y la computación, lo que significa que el diseño del hardware será muy diferente del diseño específico de la aplicación. Por lo tanto, si bien el trabajo realizado por los principales actores en el espacio, incluidos Intel, Duality, SRI, DARPA y muchos otros, sin duda están superando los límites con sus diseños basados en GPU y ASIC, es posible que no sean aplicables 1:1 a admitir casos de uso de blockchain.

Respecto al costo de desarrollo: el hardware generalizable requiere más capital para diseñar y fabricar que el hardware específico para una aplicación, pero su flexibilidad permite que el hardware se utilice en un ámbito de aplicación más amplio. Por otro lado, con el diseño específico de la aplicación, si las necesidades de una aplicación cambian y requieren soporte para un cálculo homomórfico más profundo, entonces el hardware específico de la aplicación debería combinarse con algunas técnicas de software, como MPC, para lograr el mismo fin que hardware generalizable.

Es importante tener en cuenta que FHE en cadena es mucho más difícil de acelerar que los casos de uso específicos de aplicaciones (por ejemplo, FHEML) porque requiere la capacidad de procesar cálculos más generales frente a un conjunto más específico. Para ilustrar, fhEVM devnet está restringido a TPS de un solo dígito en este momento.

Dado que necesitamos un acelerador FHE adaptado a blockchain, otra consideración es ¿qué tan transferible es el trabajo del hardware ZKP al hardware FHE?

Hay algunos módulos comunes entre ZKP y FHE, como la transformada teórica de números (NTT) y las operaciones polinómicas subyacentes. Sin embargo, el ancho de bits de NTT utilizado en estos dos casos es diferente. En ZKP, el hardware debe admitir una amplia gama de anchos de bits para NTT, como 64 bits y 256 bits, mientras que en FHE, los operandos para NTT son más cortos debido a que están representados en el sistema de números de residuos. En segundo lugar, el grado de NTT gestionado en el ZKP es, en general, superior al del caso FHE. Por estas dos razones, no es trivial diseñar un módulo NTT que logre un rendimiento satisfactorio tanto para ZKP como para FHE. Además de NTT, existen otros cuellos de botella informáticos en FHE, como el automorfismo, que no están presentes en los ZKP. Una forma ingenua de transferir hardware ZKP a la configuración FHE es descargar la tarea informática NTT al hardware ZKP y usar la CPU u otro hardware para manejar el resto del cálculo en FHE.

Para colmo de desafíos, la computación con datos cifrados con FHE solía ser 100.000 veces más lenta que con datos de texto plano. Sin embargo, gracias a los esquemas de cifrado más nuevos y a los recientes desarrollos en el hardware FHE, el rendimiento actual ha mejorado drásticamente hasta aproximadamente 100 veces más lento que los datos de texto sin formato.

Soluciones:

1. Mejora en Hardware FHE

Hay muchos equipos que construyen activamente aceleradores FHE; sin embargo, no están trabajando en aceleradores FHE que sean específicos para la computación blockchain generalizable (es decir, TFHE). Un ejemplo de un acelerador de hardware específico de blockchain es FPT, un acelerador FPGA de punto fijo. FPT es el primer acelerador de hardware que explota en gran medida el ruido inherente presente en los cálculos FHE mediante la implementación del arranque TFHE completamente con aritmética aproximada de punto fijo. Otro proyecto que podría resultar útil para FHE es BASALISC, una familia de arquitectura de aceleradores de hardware que tiene como objetivo acelerar sustancialmente los cálculos de FHE en la nube.

Como se indicó anteriormente, uno de los principales obstáculos en el diseño de hardware FHE es la interacción masiva con la memoria. Para sortear esta barrera, una posible solución es reducir la interacción con la memoria tanto como sea posible. El procesamiento en memoria (PIM) o el cálculo de memoria cercana probablemente sean útiles en este escenario. PIM es una solución prometedora para abordar los desafíos del “muro de la memoria” para los futuros sistemas informáticos, que permite que la memoria cumpla funciones tanto de computación como de memoria, prometiendo una renovación radical de la relación entre computación y memoria. En la última década, se han logrado enormes avances en el diseño de memorias no volátiles para este propósito, como la RAM resistiva, la RAM magnética de par de transferencia de espín y la memoria de cambio de fase. Utilizando esta memoria especial, se han realizado trabajos que muestran mejoras computacionales significativas en el aprendizaje automático y el cifrado de clave pública basado en celosía.

1. Software y hardware optimizados

En desarrollos recientes, el software ha sido reconocido como un componente crítico en el proceso de aceleración del hardware. Por ejemplo, aceleradores FHE destacados como F1 y CraterLake utilizan compiladores para un enfoque híbrido de codiseño de software/hardware.

A medida que avanza el espacio, podemos esperar que se diseñen compiladores completamente funcionales con compiladores FHE específicos de blockchain. Los compiladores de FHE pueden optimizar los programas FHE basándose en el modelo de costos del esquema FHE respectivo. Estos compiladores FHE podrían integrarse con compiladores aceleradores FHE para mejorar el rendimiento de un extremo a otro incorporando un modelo de costos desde un aspecto a nivel de hardware.

1. Conexión en red de aceleradores FHE: el cambio de la ampliación a la ampliación

Los esfuerzos existentes de aceleración de hardware de FHE se centran en gran medida en la "ampliación", lo que significa centrarse en la mejora vertical de un único acelerador. Por otro lado, la “ampliación horizontal” se centra en conectar múltiples aceleradores FHE mediante redes horizontales, lo que podría mejorar drásticamente el rendimiento, similar a la generación de pruebas paralelas con ZKP.

Una de las principales dificultades con la aceleración FHE es el problema de la inflación de datos: se refiere al aumento significativo en el tamaño de los datos que ocurre durante el cifrado y el cálculo, lo que plantea desafíos para el movimiento eficiente de datos entre las memorias dentro y fuera del chip.

La inflación de datos plantea un desafío importante para conectar múltiples aceleradores FHE a través de redes horizontales. Por lo tanto, el codiseño de redes y hardware de FHE será una dirección prometedora para futuras investigaciones. Un ejemplo podría incluir un enrutamiento de red adaptativo para aceleradores FHE: implementar un mecanismo de enrutamiento que ajuste dinámicamente las rutas de datos entre los aceleradores FHE en función de la carga computacional y el tráfico de red en tiempo real. Esto garantizaría tasas de transferencia de datos óptimas y una utilización eficiente de los recursos.

Conclusión

FHE reinventará fundamentalmente la forma en que protegemos los datos en todas las plataformas, allanando el camino para una nueva era de privacidad sin precedentes. Construir un sistema de este tipo requerirá avances significativos no sólo en FHE, sino también en ZKP y MPC.

A medida que nos aventuremos en esta nueva frontera, serán imprescindibles los esfuerzos de colaboración entre criptógrafos, ingenieros de software y especialistas en hardware. Sin mencionar a los legisladores, políticos, etc., ya que el cumplimiento normativo es el único camino hacia la adopción generalizada.

En última instancia, FHE estará a la vanguardia de una ola transformadora de soberanía digital, anunciando un futuro en el que la privacidad y la seguridad de los datos ya no serán mutuamente excluyentes sino inextricablemente unificadas.

Gracias especiales:

Muchas gracias a Mason Song (Mind Network), Guy Itzhaki (Fhenix), Leo Fan (Cysic), Kurt Pan, Xiang Xie (PADO), Nitanshu Lokhande (BananaHQ) por su revisión. ¡Esperamos leer sobre el impresionante trabajo y los esfuerzos que estas personas están haciendo en el campo!

Descargo de responsabilidad:

1. Este artículo está reimpreso de [HashKey Capital]. Todos los derechos de autor pertenecen al autor original [Jeffrey Hu、Arnav Pagidyala]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.