Hace unos meses, el equipo de criptomonedas de a16z publicó el Desafío Nakamotouna lista de los problemas más importantes a resolver en blockchain. El cuarto en particular llamó nuestra atención: “Cumplimiento de la privacidad programable”, ya que hemos estado pensando activamente en esto durante algún tiempo. Hoy, estamos proponiendo una primera solución utilizando el cifrado homomórfico y nuestro protocolo de contrato inteligente confidencial fhEVM (si no está familiarizado con el fhEVM, puede leer nuestros artículos sobre confidencialFicha ERC20 y subastas ciegasError: Invalid input

El fhEVM es un EVM regular con algunas precompilaciones que permiten calcular en estados encriptados usando nuestra biblioteca de cifrado homomórfico TFHE-rs. Desde la perspectiva del desarrollador, no hay criptografía involucrada: simplemente escriben código Solidity utilizando los tipos de datos encriptados que proporcionamos (euint32, ebool, etc). Una de las grandes ventajas del fhEVM frente a otras soluciones de privacidad es que todos los datos y cálculos suceden en la cadena. Esto significa que puedes tener el mismo nivel de composabilidad y disponibilidad de datos que los contratos regulares en texto plano.

Esta propiedad es clave para construir privacidad programable, ya que toda la lógica de control de acceso se puede definir en el contrato mismo. No hay nada que deba estar codificado en el protocolo, y nada que el usuario tenga que hacer fuera de la cadena para cumplir. ¡La aplicación puede hacer cumplir el cumplimiento directamente, con solo unas pocas líneas de código de Solidity!

En este artículo, mostraremos cómo construir un token ERC20 cumplidor, utilizando DIDs onchain. El código fuente de este tutorial se puede encontrar en el Carpeta de ejemplosdel repositorio fhEVM.

Abstracción de identidad a través de DIDs confidenciales en la cadena

Un Identificador Descentralizado (DID) es una identidad digital única que es emitida por una entidad como un gobierno, un registrador, una empresa o el propio usuario. Este DID puede estar vinculado a una clave criptográfica que demuestra que el usuario es el propietario del DID, como una billetera EVM. Pero también puede almacenar una serie de atributos, como la edad del usuario, nacionalidad, número de seguro social, etc. Estos atributos a su vez pueden ser utilizados para demostrar que cumples con alguna condición (llamada una 'atestación'), como ser mayor de 18 años o no ser ciudadano de Narnia.

La mayoría de los DIDs se implementan en el lado del cliente y utilizan pruebas de conocimiento cero para generar certificaciones. Si bien esto está bien en muchos casos, rápidamente se vuelve complicado cuando hay varios usuarios involucrados en una transacción, cuando se deben aplicar reglas complejas al DID o cuando se necesita mantener un conjunto común de reglas para que todos sigan. Esencialmente, es el mismo compromiso que en las aplicaciones de borde frente a las aplicaciones de nube.

Sin embargo, tener un registro centralizado de identidades descentralizadas resolvería estos problemas, ya que simplemente podrías pedir al registro que verificara que todos cumplen. También simplificaría el seguimiento de las regulaciones, ya que solo necesitarías implementarlo en un solo lugar. Una cadena de bloques sería una infraestructura perfecta para esto, ya que permitiría la composabilidad entre las identidades descentralizadas y las aplicaciones que requieren cumplimiento, así como la composabilidad entre las propias regulaciones.

Problema: ¡todo el mundo vería la identidad de cada uno!

Afortunadamente tenemos una solución: el cifrado homomórfico, y más específicamente el fhEVM! Gracias a la capacidad de tener composabilidad en estado encriptado, podemos alojar los DIDs de usuario directamente en cadena en forma encriptada, y hacer que las aplicaciones cumplan verifiquen atributos utilizando una simple llamada de contrato. La capacidad de gestionar una identidad a través de un contrato inteligente, que llamamos "Abstracción de Identidad", es similar a cómo uno puede gestionar fondos a través de un contrato inteligente con la Abstracción de Cuenta.

Este tutorial tiene 3 partes:

• La Abstracción de Identidad se realiza a través de un contrato de registro que es responsable de gestionar identidades y certificaciones. Aquí asumimos que los DIDs son identificaciones oficiales del gobierno. El registro en sí mismo es gestionado por una autoridad central (por ejemplo, el AFNIC) que puede crear registradores (por ejemplo, empresas de KYC como Onfido, Jumio, etc.) que a su vez pueden crear DIDs de usuario. El usuario luego pasa por su registrador para gestionar y actualizar sus DIDs.
• La regulación se define en un contrato que codifica un conjunto de reglas para transferencias de tokens entre individuos, basadas en la información contenida en sus DIDs. Básicamente, hace cumplir la regulación a nivel de contrato en lugar de a nivel de usuario.
• Las transferencias confidenciales compatibles se implementan en un contrato ERC20 compatible que utiliza el contrato de regulación para hacer cumplir la conformidad en las transferencias de tokens, sin realizar cambios en la API ERC20 en sí. En este ejemplo, utilizamos un contrato ERC20 confidencial, donde los saldos y montos están ocultos, pero funcionaría igual de bien con un token ERC20 regular y en texto sin formato.

Arquitectura de nuestro Protocolo de Identificador Digital Confidencial Onchain

El contrato del registro de identidad

El contrato IdentityRegistry es un registro de DIDs de usuarios que son emitidos por registradores e incluyen un conjunto de identificadores cifrados, como su nacionalidad, edad, número de seguro social, etc. Estos identificadores se almacenan como valores cifrados de 32 bits (euint32).

El contrato también maneja permisos, como:

• Permitir al propietario del contrato (por ejemplo, AFNIC) agregar, eliminar o actualizar registradores.
• Permitir a los registradores agregar, eliminar o actualizar los DIDs de usuario que crearon.
• Permitir a los usuarios otorgar acceso a contratos inteligentes a atributos específicos de sus DIDs. Es importante señalar aquí que el usuario es responsable de no dar acceso a contratos maliciosos, al igual que es responsable de no permitir que los contratos maliciosos gasten sus tokens.

Como primer paso, implementemos la lógica para crear y gestionar DIDs:

Ahora el siguiente paso es implementar la lógica para identificadores y control de acceso.

Un identificador es simplemente una cadena (por ejemplo, “fecha de nacimiento”) y un valor de 32 bits encriptado. Solo puede ser creado o actualizado por el registrador. Un usuario no puede crear sus propios identificadores, ya que queremos que sean certificados por el registrador.

Dado que los identificadores están encriptados, sin embargo, el usuario necesita dar permiso a un contrato para acceder a valores específicos, lo cual manejaremos a través de un mecanismo de control de acceso simple similar a cómo puedes permitir que un contrato gaste tus tokens ERC20.

contrato IdentityRegistry es EIP712WithModifier, Ownable

Ahora podemos concluir nuestro contrato de registro de identidad agregando los getters necesarios, con algunas condiciones y manejo de errores.

el contrato IdentityRegistry es EIP712WithModifier, Ownable

El contrato de regulación

El siguiente paso es crear nuestro contrato de regulación.

Al implementar un conjunto de reglas para transferencias entre dos individuos, es importante reconocer que estas reglas pueden evolucionar con el tiempo. Tener un único contrato inteligente que defina toda la regulación para un contexto dado, como la transferencia de dinero, significa que los contratos ERC20 no tienen que hacer un seguimiento de la regulación por sí mismos. Los gobiernos simplemente pueden actualizar este contrato, y se propagará automáticamente a todos los tokens que lo implementaron.

En el fondo, el contrato de regulación es simplemente un conjunto de condiciones que se comparan con atributos de identidad encriptados. Para evitar el mal uso, los usuarios no otorgarán acceso directo al contrato de regulación, sino que otorgarán acceso al contrato de token ERC20, que luego realiza una llamada de delegado al contrato de regulación. Este enfoque asegura que solo el contrato ERC20, en el que confía el usuario, puede acceder a su información. Tenga en cuenta que tanto el remitente como el receptor deben haber otorgado permiso al contrato ERC20 antes de que pueda ocurrir una transferencia entre ellos.

En este ejemplo, implementaremos algunas reglas básicas:

• Las transferencias dentro de un país son ilimitadas, pero las transferencias a un país extranjero están limitadas a 10,000 tokens.
• Un usuario de la lista negra no puede transferir ni recibir tokens.
• Un usuario no puede transferir tokens a un país en la lista negra.

En lugar de fallar la transacción, lo que podría revelar información sensible, simplemente estableceremos el monto de la transferencia en 0 si no se cumple una de las condiciones. Esto utiliza un operador ternario homomórfico llamado cmux: value = TFHE.cmux(encryptedCondition, valueIfTrue, valueIfFalse

El contrato ERC20 confidencial y cumplidor

Ahora que tenemos un registro de identidad y un contrato de regulación, finalmente podemos crear nuestro contrato de token compatible con la privacidad. Este contrato se llamará CompliantERC20 y tendrá las siguientes características clave:

• El saldo del usuario y la cantidad de transferencia están cifrados.
• El cumplimiento se hace cumplir en las transferencias llamando al contrato de regulación.
• Se puede otorgar visibilidad de ciertos saldos a direcciones en lista blanca (por ejemplo, reguladores)

El contrato de regulación se invoca a través de una llamada simple. Esto implica que los usuarios deben proporcionar acceso al contrato ERC20 antes de iniciar cualquier transferencia; de lo contrario, la transferencia se revertirá.

Finalmente, ahora podemos crear nuestro contrato ERC20:

De manera similar a cómo los usuarios otorgan permisos a los protocolos DeFi para gastar sus tokens, deberán otorgar permiso al contrato para acceder a los identificadores necesarios por el contrato de regulación. Esto se hace a través de una llamada a Identity.grantAccess(contractAddress, identifiers), que se puede recuperar llamando al método de vista ERC20.identifiers(). Esta lista proviene directamente del contrato ERC20Rules para permitir la actualización de propiedades.

¡El cumplimiento y la privacidad pueden coexistir!

Esperemos que este tutorial te haya demostrado que el cumplimiento no es algo difícil de construir si se dispone de las herramientas adecuadas. Si bien inicialmente construimos el fhEVM para habilitar la privacidad en la cadena de bloques, rápidamente nos dimos cuenta de que esta tecnología podría ser utilizada para la gestión de identidades y, por lo tanto, el cumplimiento programable.

El diseño propuesto aquí está lejos de ser perfecto, pero creemos que puede mejorarse fácilmente y lanzarse como un caso de uso en el mundo real, de modo que el cumplimiento ya no tenga que ser sinónimo de vigilancia.

Enlaces adicionales

• Estrella Repositorio de Github fhEVM de Zamapara respaldar nuestro trabajo.
• Revisión Documentación fhEVM de Zama.
• Obtén soporte en nuestro canales de la comunidad.
• Ayuda a avanzar en el espacio FHE con el Programa de Recompensas Zama: Crear un juego en cadena que mantenga los estados privados ocultos utilizando la privacidad programable fhEVM de Zama (15,000€ en premio).

Descargo de responsabilidad：

1. Este artículo es reimpreso de [zama]。 Todos los derechos de autor pertenecen al autor original [fhEVM]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son exclusivamente del autor y no constituyen asesoramiento de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.