WEB3DEV Español

Cover image for Definiendo el Stack de desarrollo en Web3
Juan José Gouvêa
Juan José Gouvêa

Posted on

Definiendo el Stack de desarrollo en Web3

Esta es una traducción de Juan José Gouvêa. Puedes encontrar el artículo original aquí.

¿Quieres construir en Web3? Nader Dabit identifica los componentes básicos de la construcción de bloques del stack de tecnologías Web3, en una guía introductoria.

En este próximo segmento, el ingeniero de relaciones con desarrolladores de Edge & Node, Nader Dabit, habla sobre el stack de web3 y cómo los desarrolladores pueden conceptualizar las diversas facetas de la creación en web3.

Hice la transición a web3 en abril de 2021, después de ser un desarrollador full-stack tradicional durante, aproximadamente, 10 años. Mientras me sumergía en todas estas nuevas tecnologías e ideas, lo primero que quería saber era "¿qué es un stack web3?".

Cuando construyo una aplicación web o móvil tradicional, a menudo dependo de un puñado de componentes básicos para hacer el trabajo.

  1. Servidores API/Aplicaciones (REST o GraphQL).
  2. Capa de autenticación (gestionada o manual).
  3. Base de datos.
  4. Frameworks client-side, plataformas y bibliotecas.
  5. Almacenamiento de archivos.

Usando estos componentes principales, puedo crear casi cualquier tipo de aplicación que desee o, al menos, aprovechar al máximo el camino. Entonces, ¿cómo se ve esto en Web3?

Resulta que la respuesta a esto no es tan sencilla porque:

  1. El paradigma es completamente diferente, en muchos sentidos.
  2. Las herramientas, tecnologías y el ecosistema web3 son menos maduros que en la web2.

También fue más difícil, para mí, comprender cómo ponerme en marcha y crear aplicaciones web3, ya que estaba abordando los problemas de la misma manera que lo hacía en el mundo web2.

Después de trabajar, investigar, experimentar y construir cosas durante los últimos 8 meses, me gustaría compartir lo que aprendí.

¿Qué es web3?

Antes de definir qué es el stack web3, intentemos definir la web3.

Hay innumerables definiciones dependiendo de a quién le preguntes pero, para mí, esta definición es perfecta:

Web3 es un stack de protocolos que permite aplicaciones totalmente descentralizadas.

Con este stack de tecnología descentralizada, podemos comenzar a desarrollar aplicaciones descentralizadas que tienen sus propias implicaciones y características establecidas.

Algunas de estas características posibles gracias a web3 son:

  • Infraestructura web descentralizada.
  • Titularidad (de datos, contenido y plataforma).
  • Pagos digitales nativos.
  • Identidad auto-soberana.
  • Infraestructura distribuida, confiable y robusta.
  • Back-ends abiertos, públicos y componibles.

Si bien, algunas de las aplicaciones basadas en stacks descentralizados reemplazarán a sus predecesoras, un nuevo paradigma de aplicaciones también ha sido posible gracias a las nuevas primitivas habilitadas por los blockchain.

Los pagos digitales nativos y el back-end de la infraestructura pública como: el machine learning, los dispositivos móviles, la realidad virtual y otras tecnologías primitivas, plataformas y bloques de construcción, permiten crear tipos de aplicaciones completamente nuevos, algunos aún por imaginar.

¿Esto quiere decir que todo será reemplazado por web3? No necesariamente. Si bien creo que construir sobre un stack de tecnología descentralizada es una opción mucho mejor para ciertos tipos de aplicaciones, como casi cualquier decisión técnica, depende de lo que estés construyendo.

Ahora comencemos a sumergirnos en el stack web3, dividido en este conjunto de categorías:

  • Blockchain.
  • Entorno de desarrollo de blockchain.
  • Almacenamiento de archivos.
  • Protocolos de datos fuera de la cadena.
  • API (indexación y consulta).
  • Identidad.
  • Cliente (frameworks y bibliotecas).
  • Oráculos.
  • Otros protocolos.

El stack web3<br>

Blockchain

Hay innumerables Blockchains en las que puedes elegir desarrollar. No hay una sola que sea "la mejor". En su lugar, debes considerar las diversas ventajas y desventajas entre ellas.

Una cosa que suele ser importante para mí, cuando estoy aprendiendo algo nuevo, es la idea de aplicar el Principio de Pareto a lo que estoy aprendiendo. Es decir: cuál es la forma más eficiente de aprovechar al máximo el tiempo y el esfuerzo. Al seguir esta idea, puedo obtener la máxima tracción e impulso, mientras aprendo algo nuevo en el menor tiempo posible.

En el mundo de Blockchain, aprender Solidity y EVM (Ethereum Virtual Machine) podría ser la mejor opción para comenzar como desarrollador de blockchain. Con este conjunto de habilidades (y stack tecnológico), puedes construir no solo para Ethereum, sino también para otras Layers2 de Ethereum, cadenas laterales e incluso otras blockchains como Avalanche, Fantom y Celo.

Dicho esto, Rust está comenzando a ser cada vez más popular en el mundo de blockchain, junto a Solana, NEAR, Polkadot y otros que cuentan con soporte Rust de primera clase. Probablemente no te equivocarás aprendiendo cualquiera de estas, pero para el principiante, diría que Solidity seguirá siendo la mejor opción, si alguien me pregunta hoy.

Además de este consejo, aquí hay un ejemplo incompleto de blockchains que tienen una combinación sólida de tecnología, utilidad, comunidad, impulso y viabilidad futura:

  • Ethereum - la plataforma original de los smart contracts.

  • ZK: ZKSync, Starknet, Hermez: son los Layer2 de Ethereum de alto rendimiento pero no son compatibles de forma nativa con EVM.

  • Optimistic rollups: Arbitrum & Optimism: son los Layer2 de Ethereum, compatibles con EVM (obtén más información sobre las diferencias entre rollups optimistic y ZK aquí).

  • Polygon - es la sidechain de Ethereum.

  • Solana - es de alto rendimiento, tiene transacciones económicas y tiempos de bloqueo rápidos, pero es más difícil de aprender que EVM (Rust).

  • NEAR - es el Layer1 de la blockchain, puede escribir contratos inteligentes en Rust o Assemblyscript.

  • Cosmos - es un ecosistema de blockchains interoperables.

  • Polkadot - es la plataforma informática basada en blockchains, que permite que las mismas realicen transacciones entre sí, creando una internet interconectada de cadenas de bloques.

  • Fantom - es el Layer1 compatible con EVM.

  • Avalanche - es el Layer1 compatible con EVM.

  • Celo - es el Layer1 compatible con EVM, diseñado para facilitar que cualquier persona con un teléfono inteligente envíe, reciba y almacene criptomonedas.

  • Tezos - el Layer1 no es compatible con EVM. Muchos proyectos NFT la están usando.

Al interactuar con una red, deberás usar un endpoint RPC.

Hay algunas maneras de hacer esto:

  1. Accesando a un endpoint RPC público.
  2. Ejecutando tus propios nodos.
  3. Accediendo a un nodo como proveedor de servicios.
  4. Accediendo a un proveedor de nodos descentralizados como un servicio.

Los endpoints públicos de RPC, a menudo, se proporcionan a través de la red pero, para la mayoría de las dapps de producción, querrás aprovechar tus propios endpoints, ya que no son estables ni se recomiendan para entornos de producción.

Hay un puñado de proveedores de servicios. Estos son algunos de ellos:

También hay una solución web3/descentralizada: Pocket Network, que parece estar ganando terreno.

Cualquiera de estas opciones es probablemente una buena apuesta para interactuar directamente con tu red.

Entornos de desarrollo Blockchain

Para el desarrollo en la EVM, hay algunos buenos entornos de desarrollo disponibles:

  • Hardhat (JavaScript) es una opción más nueva pero que está ganando cada vez más popularidad. Sus documentos son excelentes, las herramientas y la experiencia del desarrollador están pulidas y, es lo que personalmente he estado usando para crear dapps.

  • Truffle (JavaScript) es un conjunto de herramientas para crear y desarrollar aplicaciones en EVM. Es maduro, probado en batalla y bien documentado. Ha existido por algún tiempo y muchos desarrolladores lo usan.

  • Foundry es un nuevo entorno de desarrollo de Solidity de Paradigm que promete mucho. Los aspectos claves más destacados son: la capacidad de escribir pruebas en Solidity, soporte para fuzzing y velocidad (está escrito en Rust). Escribí una introducción separada para esto aquí.

  • Brownie es un Framework de prueba y desarrollo basado en Python para contratos inteligentes, para el desarrollo de Solidity/EVM.

Para el desarrollo de Solana, Anchor se está convirtiendo, rápidamente, en el punto de entrada para nuevos desarrolladores. Proporciona una CLI para scaffolding, creación y prueba de programas de Solana, así como bibliotecas de clientes que puedes usar para crear interfaces. También incluye un DSL que abstrae muchas de las complejidades que los desarrolladores suelen encontrar cuando comienzan con el desarrollo de Solana y Rust.

Almacenamiento de archivos

¿Dónde almacenamos las imágenes, videos y otros archivos en web3? Almacenar cualquier cosa tan grande en la cadena es, generalmente, prohibitivamente costoso, por lo que probablemente no queramos almacenarlos allí.

En cambio, podemos algunos de los pocos protocolos de almacenamiento de archivos:

  • IPFS - Protocolo de sistema de archivos punto a punto.
    pros: es confiable, bien documentado, con un gran ecosistema.
    contras: si los datos no están anclados, se pueden perder.

  • Arweave: te permite almacenar datos de forma permanente por una simple tarifa de transacción. Soy fanático de Arweave y escribí un artículo de blog aquí.

  • Filecoin: de Protocol Labs, el mismo equipo que creó IPFS, es un protocolo diseñado para proporcionar un sistema de almacenamiento de datos persistente. Hay un montón de formas en que los desarrolladores pueden construir en Filecoin, incluyendo web3.storage, lo cual es realmente genial.

  • Skynet: aún no lo he usado en producción, pero lo probé y parece funcionar bien. La API aquí se ve muy bien. Tengo preguntas como: cuánto tiempo se conservan los datos y la interoperabilidad de Skynet con otros protocolos.

Protocolos de datos off-chain

Además del almacenamiento de archivos y el almacenamiento en cadena, es posible que también debas almacenar datos fuera de la cadena. Puedes usar este tipo de soluciones de manera similar a cómo podrías usar una base de datos en un stack de tecnología tradicional, pero en cambio, se replican en una cantidad n de nodos en una red descentralizada y, por lo tanto, son más confiables (al menos en teoría).

Algunas opciones son:

  • Ceramic Network: es una plataforma descentralizada de código abierto para crear, almacenar y compartir datos. Ceramic también tiene un buen protocolo de identidad, del que hablaré más adelante. Probablemente, mi solución de almacenamiento fuera de cadena favorita en este momento. Aquí hay una demostración realmente genial.

  • Textile ThreadDB: es una base de datos de múltiples partes construida sobre IPFS y Libp2p. Si lo entiendo correctamente, es posible que esté experimentando un cambio importante de API en este momento. Lo probé y parece prometedor, pero los documentos y DX necesitan mejoras.

  • GunDB: una base de datos descentralizada punto a punto. Gun existe desde hace mucho tiempo y se han creado algunas aplicaciones muy interesantes con él.

En términos de madurez, creo que el ecosistema de soluciones de almacenamiento off-chain aún no está donde debe estar, para construir algunos de los casos de uso más avanzados que algunos desarrolladores podrían desear. Algunos desafíos aquí son: los datos en tiempo real, la detección y resolución de conflictos, la autorización de escritura, la documentación y la experiencia general del desarrollador.

La integración de soluciones de datos fuera de la cadena con protocolos de blockchain es uno de los últimos grandes obstáculos que debemos superar antes de tener una pila de protocolos completamente descentralizada, capaz de admitir cualquier tipo de aplicación.

API (indexación y consulta)

Hay muchas diferencias en la forma en que interactuamos y construimos sobre blockchains versus bases de datos, en el stack tradicional. Con blockchains, los datos no se almacenan en un formato que pueda consumirse de manera eficiente o fácil, directamente desde otras aplicaciones o interfaces.

Las blockchains están optimizadas para operaciones de escritura. A menudo se escucha que la innovación se centra en las transacciones por segundo, el tiempo de bloque y el costo de la transacción. Los datos de las blockchains se escriben en bloques a lo largo del tiempo, lo que hace imposible todo lo que no sean operaciones básicas de lectura.

En la mayoría de las aplicaciones, necesitas funciones como: datos relacionales, clasificación, filtrado, búsqueda de texto completa, paginación y muchos otros tipos de capacidades de consulta. Para hacer esto, los datos deben indexarse ​​y organizarse para una extracción eficiente.

Tradicionalmente, este es el trabajo que realizan las bases de datos en el stack centralizado, pero esta capa de indexación se ha perdido en el stack web3.

The Graph es un protocolo para indexar y consultar datos de blockchain que facilita mucho este proceso y ofrece una solución descentralizada para hacerlo. Cualquiera puede crear y publicar APIs de GraphQL abiertas, llamadas subgráficos, lo que facilita la consulta de los datos de la blockchain.

Para obtener más información sobre The Graph, consulta los documentos aquí o mi tutorial aquí.

Identidad

La identidad es un paradigma completamente diferente en web3. En web2, la autenticación casi siempre se basa en la información personal del usuario. Esta información generalmente se recopila a través de un formulario o un proveedor de OAuth que le pide al usuario que dé a cambio el acceso a la aplicación.

En la web3, la identidad gira completamente en torno a la idea de carteras y criptografía de clave pública.

Si bien el nombre "cartera" cumple su propósito, he notado que las personas nuevas en web3 encuentran la terminología confusa en lo que respecta a la autenticación y la identidad. Espero que en el futuro podamos encontrar alguna otra forma de transmitir lo que es una cartera, ya que combina aspectos financieros pero también identidad y reputación.

Como desarrollador, deberás comprender cómo acceder e interactuar con la cartera y la dirección de un usuario de varias maneras.

En un nivel muy básico (y un requisito muy común), es posible que debas solicitar acceso a la billetera del usuario. Para hacer esto, generalmente podrás acceder a la cartera del usuario en la ventana del contexto (navegador web) o usar algo como WalletConnect o el Wallet Adapter de Solana.

Por ejemplo, si tienes una cartera Ethereum disponible, podrás acceder a window.ethereum. Lo mismo para Solana (window.solana), Arweave (window.arweaveWallet) y un puñado de otros. WalletConnect es bueno para la web móvil y React Native, ya que permite a los usuarios autorizar el uso de sus billeteras móviles directamente desde el dispositivo.

Si deseas manejar la autenticación tú mismo, puedes permitir que el usuario firme una transacción y luego descifrarla en algún lugar para autenticar al usuario, pero esto generalmente requiere un servidor. Aquí hay un ejemplo de cómo se vería esto usando una cartera EVM, y aquí hay un ejemplo de cómo hacer esto con Solana/Phantom.

¿Qué pasa con la gestión de perfiles de usuario de una forma descentralizada? Ceramic Network ofrece el protocolo y el conjunto de herramientas más sólidas para la gestión de identidad descentralizada. Recientemente lanzaron un artículo que describe algunas de sus últimas actualizaciones y brinda algunas pautas sobre cómo funcionan todas las herramientas juntas. Comenzaría allí y luego exploraría los documentos para comprender cómo comenzar a construir, y consideraría consultar mi proyecto de ejemplo aquí, que usa Ceramic self.id.

Si deseas obtener los registros de usuarios ENS en texto, la biblioteca ensjs ofrece una buena API para obtener datos de usuario:

const ens = new ENS({ provider, ensAddress: getEnsAddress('1') })

const content = await ens.name('sha.eth').getText('avatar')

SpruceID es algo que también parece prometedor pero aún tengo que probarlo.

Tanto Ceramic como Spruce implementan la especificación DID W3C, que en sí misma, también es algo que consideraría un componente básico de web3. Dicho esto, cualquier implementación centralizada de los DIDs va en contra de lo quela especificación pretende lograr.

Cliente

En lo que respecta a los Frameworks de JavaScript, realmente puedes construir con cualquier cosa que desees, ya que los SDK de blockchain del lado del cliente son en su mayoría independientes del Framework. Dicho esto, se construye una cantidad abrumadora de proyectos y ejemplos en React. También hay un puñado de bibliotecas como Solana Wallet Adapter que ofrecen utilidades adicionales para React, por lo que diría que aprender o familiarizarse con React, probablemente, sea una decisión inteligente.

Para los SDK del lado del cliente de Ethereum, están web3.js y ethers.js. Para mí, Ether.js es más amigable y tiene mejor documentación, aunque web3.js existe desde hace más tiempo.

En Solana, probablemente estarás trabajando con @solana/web3.js y/o Anchor. Considero que las bibliotecas de cliente de Anchor son mi forma de crear programas de Solana, ya que de todos modos estoy usando el Framework de Anchor, y lo he encontrado mucho más fácil de entender que @solana/web3.js.

Oracles

Los oráculos permiten a los desarrolladores acceder a datos del mundo real y sistemas externos desde un contrato inteligente.

Por ejemplo, la mayoría de las aplicaciones financieras requieren el conocimiento de los datos y eventos que suceden en el mundo real, off-chain, por lo que los oráculos son especialmente importantes en DeFi.

Chainlink es un Oracle que permite el acceso a datos del mundo real y computación off-chain mientras mantiene las garantías de seguridad y confianza, inherentes a la tecnología blockchain.

Flux es un Oracle cross-chain que proporciona contratos inteligentes con acceso a fuentes de datos económicamente seguras.

Otros protocolos

Radicle es un protocolo de colaboración de código descentralizado basado en Git. Podría considerarse como una versión descentralizada de GitHub.

Livepeer es una red de transmisión de video descentralizada. Es madura y ampliamente utilizada con más de 70.000 GPUs en vivo en la red.

Conclusión

Esta publicación será un documento vivo que actualizo a medida que aprendo, experimento y obtengo comentarios de los desarrolladores que construyen la web3.

Si tienes algún comentario o idea sobre algo que olvidé mencionar aquí, por favor comunícate y comparte tus ideas conmigo. Es emocionante ver toda esta actividad en torno a web3, con los desarrolladores interviniendo e involucrándose. Si bien la infraestructura aún está evolucionando, la visión de construir protocolos y aplicaciones verdaderamente descentralizadas, que permitan a las personas coordinarse sin tener que otorgar poder y control a las grandes empresas es importante, y estamos cerca de hacer realidad esta visión.

Discussion (0)