01/07/2022 - Meeting notes libs

Asistentes

@Victor Nieves Sanchez
@Garcia-Alvarez Roberto
@Daniel de la Sota Blanchart
@Iñigo Garcia
@Antonio González Sanz
@Former user (Deleted)
@Iker Ruiz de Infante
@Pelayo García Conde
@Manuel Gallego Chinchilla

PUNTOS DEL DÍA:

Sesión grabada. Link al video en el siguiente enlace: https://gfi1-my.sharepoint.com/:v:/g/personal/victor_nieves_inetum_com/EWcYy0aYEVlOipve-xUpDZQBVKf7oyO2dcAgmVGmAcP2eg?e=AFG5Z0

Contraseña para acceder al video : “hardhat“

Técnologías a usar en los repositorios de Smart contracts:
-Dos posibilidades, mantener dos versiones o una única con hardat y empujar esa. La idea es empezar a trabajar en el repositorio de hardhat y dejar desatendido el de truffle una vez terminado lo que queda de la documentación. Se pretende seguir el mismo procedimiento que ha ocurrido con la versión 1.0 de los smart contracts. Para llevar a cabo esto, la idea es crear un repo nuevo para dejar el actual intacto por si a futuro se quiere retomar o se quiere volver a utilizar.
- HARDHAT: ethers funciona mejor en back, y tiene una herrramienta de 'console log' permite depurar errores de una manera más sencilla. Tanto es así que debido a esta facilidad que incorpora hardhat en proyectos grandes como como Uniswap protocol se esta apostando por este framework. Además, permite gestionar las configuraciones de una manera mas sencilla.
-El lenguaje que utiliza es JavaScript.
-No contiene migrations al contrario que truffle.
-Hardhat, tiene su propia red, Waffle, que para ejecutar en local y hacer pruebas funciona muy bien. -Hardat esta basado en ethers y es un poquito mas ligero.
-Al utilizar ethers la implementación de la librería quedaría muy simplificada y mucho mas ligera que la que hay ahora implementada con web3.
- TRUFFLE: web3js esta muy centrado en navegador, por tanto temas de back no se estan centrando en eso, lo cual puede ser un inconveniente para seguir utilizando esta tecnología.
Tecnologías a usar en los repositorios de Libs:
-La idea es sacar una versión de Alastria Identity Lib de web3 creando un fork del repositorio actual y el repositorio actual de la librería transformarlo a ethersjs.
-Con este cambio se quiere seguir los principios SOLID para que se pueda cambiar de una librería a otra sin ningún problema.
-A futuro la idea es abandonar la librería de web3 como va a ocurrir con el repositorio de smart contracts de truffle.
-Por último, tras el cambio a hardhat el cambio a etherJS es lo lógico.
Nueva arquitectura de la librería:
- Separar la parte de tokens de la parte de transacciones para conseguir simplificar y de esta manera instalarse la parte que se quiera utilizar unicamente, evitando tener que descargarse e instalar todo cuando solo se quiere hacer uso de una parte
-El problema es que si se cambia la arquitectura de la librería no serían compatibles la versión de la librería de ethersJS con la de web3.
-La nueva arquitectura se aplicaría en ethers y no en web3 y se crearía un repositorio nuevo.
-En la parte de tokens también se quiere meter una validación de los esquemas de dichos objetos para garantizar que estan bien formados.
Modificar el fichero UserIdentity.ts por un signer que permita firmar o no las transacciones dependiendo de los constructores utlizados:
-Este fichero se encarga de firmar transacciones y de la gestión del nonce.
-La librería de alastria no debería encapsular la firma ni enviar dicha transacción a blockchain. Esto se debería de realizar por fuera de la librería y que fuese el desarrollador quien se encargue de hacer esto.
-La propuesta es montar un signer que de la posibilidad de firmar y hacer el resto de cosas, pero también que permita devolver los objetos y transacciones en claro. Para ello la idea es duplicar el constructor con diferentes parámetros para que el desarrollador pueda utilizar uno u otro indistintamente.