lunes, junio 26, 2023

Latch Web3: Un pestillo de seguridad para SmartContracts (Parte 4)

Para implementar un protección Latch en un SmartContract, hay que realizar una serie de procesos que vamos a ver a continuación. En las partes anteriores hemos visto cómo funciona el concepto, ahora vamos a ver cómo se integra Latch Web3 en un SmartContract y cómo funciona desde el punto de vista de un usuario.

Figura 25: Latch Web3: Un pestillo de seguridad para SmartContracts (Parte 4)

Para poder crear una DApp que tenga un SmartContract con funciones que el usuario pueda abrir o cerrar con su Latch, necesitamos entender cuáles son los elementos que entran en juego en esta arquitectura, poniendo en el medio la arquitectura de Latch.

Componentes de Latch

La arquitectura de Latch la vamos a resumir en los siguientes elementos, que cada uno tendrá su importancia en el funcionamiento:
  • Latch Backend: Es el servidor de Latch. Este servidor gestiona los Latches para las apps del mundo Web2, y va a manejar el Latch SmartContract para mantener los "Latches Web3" de las aplicaciones Web3. Es un servicio web al que los desarrolladores Web2 llaman para las opciones de Pareado, Despareado y Consulta del Latch, y los desarrolladores Web3 tendrán que llamar para las opciones de Pareado y Despareado, ya que la opción de consultar un Latch Web3 se hará con una llamada del SmartContrat.
  • Latch Developer: Es una cuenta Web2 que un desarrollador tendrá que sacarse en el Latch Backend para poder crear las aplicaciones Web2 y Web3 para las que se van a crear Latches o Latches Web3 que protegerán partes de las aplicaciones Web2 y/o Web3.
  • Latch ApplicationID: Cuando un desarrollador quiere proteger una aplicación Web2 o Web3, se generar una identidad para esa aplicación en el mundo Latch, que se llama ApplicationID. Se utilizará para el proceso de pareado y despareado de usuarios a aplicaciones.
  • Latch UserID: Cada usuario que quiere poner un 2FA en sus aplicaciones, tanto Web2 como Web3, primero tiene que tener una cuenta en el servidor de Latch. Esta es cuenta con la que gestionará el pareado, la apertura y el cierre de latches, y con la que un usuario iniciará sesión en la app de Latch en el terminal móvil. Aunque se proteja un SmartContract del mundo Web3, Latch sigue siendo una aplicación del mundo Web2.
  • Latch App: Es la aplicación móvil que maneja el usuario para realizar el pareado y despareado de Latches, para cambiar el estado. Se autentica siempre contra el Latch Backend. Es una arquitectura Web2 clásica.
Figura 26: Latch App con el nuevo diseño
  • Latch Pairing Token: El Token de pareado es un TOTP que se genera el Latch USERID en la app móvil de Latch para generar un Latch en una Latch Application. Es decir, el usuario pide un Token de pareado en la app de Latch, se lo entrega a la aplicación en la que quiere crear el Latch, y la aplicación hablará con el Latch Backend para crear el Latch. El Latch concreto será lo que llamamos AccountID que explico aquí.
  • Latch AccountID: Este es el Latch. Cuando se hace un proceso de Pareado, lo que se crea en la base de datos de Latch Backend es un AccountID, cuando se desparea un usuario de un ApplicationID se elimina este AccountID, cuando se cambia el estado del Latch se cambia el valor de este AccountID y cuando se consulta el estado de un Latch, se consulta el estado del AccountID. En el mundo Web2, este AccountID es necesario controlarlo en las aplicaciones protegidas por Latch. En el mundo Web3, vamos a ver que este AccountID no lo utilizamos para consultar el estado desde los SmartContract de la DApp que se protege, ya que utilizaremos la dirección pública de la Wallet del usuario. No obstante, en el mundo Web3 este AccountID sigue existiendo en el Backend de Latch y es lo que cambia el usuario de Web3 desde su app de Latch en el terminal móvil.
De toda esta parte primera, que tiene más que ver con "Latch Web2", podéis ver el seminario de "Cómo integrar Latch en aplicaciones .NET" del gran Ioseba Palop. Tienes también los tutoriales de cómo usar e integrar Latch en plataformas de todo tipo, así como en aplicaciones escritas en Java, PHP, Python, etcétera, en la lista de vídeo-tutoriales de Latch.


Ahora vamos la parte que hemos extendido para que se puedan integrar Latch Web3 en SmartContracts que dan soporte a DApps. Para ello, es importante identificar los siguientes elementos.
  • Latch SmartContract: Nuestro Latch BackEnd se ha extendido y tiene una pieza nueva en forma de SmartContract que gestiona nuestra DApp. Es decir, el Latch SmartContract es una extensión de Latch Backend en una cadena de bloques. De momento, está desplegado solo en Polygon, porque aún estamos en fase alfa de este servicio. Es el que va a permitir a cualquier SmartContract de la red Polygon consultar el estado de los Latches. Además, cuando un usuario de Latch cree o cambie el estado de un AccountID en su aplicación móvil de Latch, el Latch BackEnd utilizará este SmartContract para anclar el estado de ese Latch Web3 de ese usuario en la BlockChain de Polygon.
Figura 28: Diagrama de arquitectura Latch Web3.
Market SC y App Client son la DApp y el SC de la Dapp a proteger.
  • Latch Web3 Developer Wallet: Un desarrollador que quiera usar Latch para proteger el SmartContract de una Dapp, deberá tener una Wallet. Esta la va a necesitar para firmar la creación de la Latch Web3 Application.
  • Latch Web3 User Wallet: Si el usuario quiere firmar un transacción en el SmartContract de una DApp, tendrá obligatoriamente que tener una Wallet. Si quiere tener un Latch Web3 para proteger su cuenta en ese SmartContract de la Dapp, deberá tener un usuario de Latch también. Es decir, esta wallet es la identidad Web3 del usuario en la Dapp con la que se parea un Latch UserID.
  • Latch Web3 Account Status: Este es el equivalente al Latch AccountID de Web3 en la Web3. En este caso, el Latch Web3 Account Status es un valor que se almacena en un bloque de la BlockChain de Polygon. Este valor lo escribe y lo actualiza el Latch SmartContract manejado por el BackEnd de Latch, y lo consulta el SmartContract de la DApp protegida por Latch mediante llamadas al Latch SmartContract.
  • Latch Web3 Application (APP_ID): Para que se puedan parear usuarios de Latch con el SmartContract de la Dapp, es necesario que el Latch Developer creer una Latch Web3 Application. Para ello, deberá firmar la creación de esta aplicación con su Latch Web3 Developer Walled. Y se creará un ApplicationID que se utilizará para el pareado y despareado de Latches, así como para el cambio de estado de estos en el BackEnd de Latch.
  • Latch Web3 Application Secret Key: Para poder llamar a la función de parear o desparear, el desarrollador deberá utilizar una contraseña, en forma de SECRET_KEY que recibirá cuando se cree la Latch Web3 Application en la herramienta de administración de Latch.
Vale, ya casi estamos terminando, que nos quedan solo dos elementos más, propios de la DApp que vamos a fortificar con Latch Web3. Los elementos son, simplemente, el Backend de la DApp y el SmartContract de la DApp. Y cada uno deberá realizar diferentes acciones en Latch.
  • DApp SmartContract: Es el encargado de la lógica Web3 que hay detrás de una DApp. Deberá integrar las capacidades de Latch, y luego en cada llamada de ejecución que reciba desde una dirección pública de la wallet de un usuario, podrá consultar el estado del Latch Web3 de ese usuario mediante una llamada la Latch SmartContract usando la función getStatus() del SmartContract de Latch, que devolverá el estado del Latch para cada usuario.
  
Figura 29: SmartContract a proteger is Latcheable  
 
Para poder hacer uso de esta función, deberá importar el fichero Latcheable.sol y heredar de Latcheable. Para desplegar el SmartContract protegido con Latch se puede usar cualquiera de las herramientas habituales: remix, hardhat… ya que el despliegue del SmartContract Latcheable no tiene nada especial o diferente de cualquier otro SmartContract. Latcheable tiene un modificador (isLatcheable) que se utilizará en todos aquellos métodos del Smart Contract que se quieran proteger.   

Figura 30: Latcheable.sol en GitHub

También debes configurar Latch Proxy para la Blockchain seleccionada. Para que el SmartContract pueda consultar adecuadamente el estado del Latch es necesario indicar a nuestro contrato la dirección del contrato de Latch en esa Blockchain. Para ello, se deberá modificar el valor PROXY_LATCH (que aparece en nuestro contrato al haber heredado de la librería Latcheable.sol) invocando al método llamado setProxyLatch. En la imagen anterior se ver la función setProxyLatch en Latcheable.sol en GitHub.
 
Este valor es diferente si estamos en mainnet o testnet. También podrá cambiar entre distintas cadenas de Blockchainsa futuro. Valores a utilizar para PROXY_LATCH.
 
- Testnet (Mumbai): 0xEa8dA5e902664Cf5E8a4235A0dd6dF65949706e4 
- Mainnet (Polygon): 0x3Ce3c3d135A2D194A318B74f35Deefc28f431dde  

A continuación, un ejemplo usando remix, donde ejecutamos la operación setProxyLatch:

Figura 31: Ejemplo de despliegue con Remix,
configurando proxyLatch en TestNet.

Una vez desplegado el contrato, es necesario guardar la dirección (address) del contrato para poder darlo de alta posteriormente en el panel de aplicaciones de Latch Web3.  

Es importante notar que, con esta arquitecta, actualmente el pestillo de Latch será único para todos los métodos protegidos. Es decir, un usuario podrá tener un Latch por SmartContract a proteger. El soporte a operaciones, que permite que un usuario maneje ene latches en una aplicación estará disponible en versiones posteriores. 
    • DApp SmartContract: Este será el encargado del proceso de pareado y despareado de los Latches. Para ello, deberá llamar a las funciones de pareo y de despareo en formato Web3 y haciendo uso de ApplicationID, el Token de Pareado, el Secret Key para garantizar que es el dueño de la Latch Web3 Application, y la dirección pública del Wallet del usuario que está creando el Latch, que lamamos WEB3WALLET, y que es una dirección Ethereum pública del usuario que desea parear el servicio, y por último, para que no pueda crear un Latch Web3 cualquiera, el valor WEB3SIGNATURE, que es una firma de la cadena “Latch-Web3” por parte del usuario con su clave privada, y que es es una forma de certificar que el usuario dispone de dicha clave privada.
    Figura 32: Ejemplo de pareado para generar un Latch Web3

    Estos son todos los elementos que hay que conocer, y que aunque parecen muchos, la verdad es que no son tantos y cuando pones cada uno en su sitio todo tiene sentido. Pero será más fácil en la siguiente parte que veremos el paso a paso para crear un SmartContract con Latch Web3 en el orden adecuado, y podremos ver en funcionamiento el sistema con nuestro ejemplo hecho sobre el Market de NFTs de Telefónica.

    a las

    No hay comentarios:

    Publicar un comentario