Respuestas>Más información sobre la arquitectura de la infraestructura de Web3>Cómo funciona la infraestructura de Web3
Cómo funciona la infraestructura de la Web3
// Tags
Infraestructura Web3Arquitectura de las dApps
En resumen: La infraestructura Web3 es el conjunto de herramientas, servicios y protocolos que permiten a las aplicaciones leer y escribir en redes blockchain. A diferencia de las aplicaciones web tradicionales, que se basan en bases de datos centralizadas controladas por una sola empresa, las aplicaciones Web3 (dapps) utilizan la cadena de bloques como su «fuente de verdad» y requieren una pila de infraestructura especializada para interactuar con ella. Esta pila incluye conexiones con monederos para la autenticación de usuarios y la firma de transacciones, puntos finales RPC para comunicarse con los nodos de la cadena de bloques, indexadores para que los datos en cadena sean consultables, almacenamiento descentralizado para archivos de gran tamaño y redes de Capa 2 para el escalado. Comprender cómo encajan todas estas piezas es esencial para cualquier desarrollador que trabaje con la cadena de bloques.
La explicación sencilla
Una aplicación web tradicional tiene una arquitectura sencilla: el usuario abre un navegador, el navegador carga una interfaz de usuario desde un servidor web, la interfaz de usuario se comunica con una API de backend y el backend lee y escribe en una base de datos. La empresa que gestiona la aplicación controla todas las capas: los servidores, la base de datos, la API y las normas sobre quién puede acceder a qué.
Una aplicación Web3 sustituye la base de datos centralizada por una cadena de bloques. Pero las cadenas de bloques no son bases de datos. No se pueden ejecutar consultas SQL en ellas. No es posible conectarse a ellas con un controlador de base de datos estándar. Tampoco se pueden escribir datos en ellas llamando a una API con una clave secreta. Interactuar con una cadena de bloques requiere una pila de infraestructura fundamentalmente diferente, y comprender esa pila es el primer paso para crear dapps con calidad de producción.
La diferencia fundamental radica en el modelo de transacción. En una aplicación tradicional, el backend escribe en la base de datos utilizando sus propias credenciales. En una aplicación Web3, el usuario escribe en la cadena de bloques firmando las transacciones con su propia clave privada, a través de su propio monedero. La aplicación facilita este proceso, pero nunca tiene acceso directo de escritura al estado en cadena del usuario. Este cambio de datos controlados por el servidor a datos controlados por el usuario es lo que hace que Web3 sea «descentralizada», y también es lo que hace que la infraestructura sea más compleja.
¿En qué se diferencia la infraestructura de la Web3 de la de la Web2?
La forma más clara de entender la infraestructura de la Web3 es compararla con la pila de la Web2, que la mayoría de los desarrolladores ya conocen. Los datos se almacenan en un lugar diferente y, en consecuencia, la forma de leerlos y escribirlos cambia.
Aspecto
Web 2.0
Web3
Fuente de la verdad
Base de datos centralizada
Blockchain
¿Quién introduce los datos?
Backend de la aplicación con sus propias credenciales
Usuario mediante firma de monedero
Identidad
Nombre de usuario y contraseña
Dirección del monedero
Acceso a los datos
Consultas directas a la base de datos
Puntos finales RPC e indexadores
Almacenamiento de archivos
Servidores en la nube
IPFS redes similares
Dado que no se puede consultar una cadena de bloques como si fuera una base de datos, la mayoría de las lecturas se realizan a través de un endpoint RPC para búsquedas sencillas y mediante la indexación de la cadena de bloques para consultas complejas y estructuradas.
La arquitectura de una dapp
Una dapp de producción típica consta de varias capas, cada una de las cuales cumple una función distinta. El frontend es la interfaz de usuario, normalmente una aplicación web desarrollada con React, Next.js o marcos similares. El frontend se encarga de la visualización, las entradas del usuario y la interacción con el monedero. Se conecta al monedero del usuario (MetaMask, Phantom, etc.) a través de una API de proveedor (como ethers.js o wagmi) que permite a la dapp solicitar direcciones de monedero, mostrar saldos y solicitar firmas de transacciones.
El monedero es la identidad del usuario y su mecanismo de autenticación. En lugar de iniciar sesión con un nombre de usuario y una contraseña, los usuarios de Web3 conectan su monedero. El monedero proporciona la dirección pública del usuario (su identidad) y la capacidad de firmar transacciones (su autorización). Cuando la dapp necesita escribir datos en la cadena de bloques (enviar tokens, interactuar con un contrato inteligente, acuñar un NFT), crea una transacción, la envía al monedero para que la firme y, a continuación, el monedero difunde la transacción firmada a la red.
Los puntos finales RPC son la puerta de enlace entre la dapp y la cadena de bloques. Todas las operaciones de lectura (comprobar un saldo, consultar el estado de un contrato inteligente, obtener un recibo de transacción) y todas las operaciones de escritura (enviar una transacción firmada) pasan por un endpoint RPC. El endpoint a un nodo de la cadena de bloques que procesa la solicitud y devuelve el resultado. La elección del proveedor de RPC influye directamente en la velocidad, la fiabilidad y la precisión de los datos de tu aplicación.
El backend (opcional, aunque habitual en entornos de producción) se encarga de la lógica fuera de la cadena que no pertenece a la cadena de bloques: gestión de sesiones de usuario, agregación de API, almacenamiento en caché, análisis, procesamiento de webhooks e integración con servicios tradicionales. Muchas dapps también utilizan un backend para gestionar el envío de transacciones desde el lado del servidor en el caso de operaciones que no requieren la firma de la cartera del usuario (como operaciones administrativas o metatransacciones sin gas).
Los indexadores transforman los datos sin procesar de la cadena de bloques en bases de datos en las que se pueden realizar consultas. La cadena de bloques en sí misma no admite consultas complejas. No es posible pedirle «muéstrame todos los NFT que posee esta dirección» o «¿cuál es el volumen total negociado hoy en este DEX?» utilizando métodos RPC estándar. Los indexadores (como The Graph o los flujos personalizados creados con Quicknode Streams) procesan cada bloque, descodifican las transacciones y los eventos, y almacenan los resultados en una base de datos que admite consultas SQL o GraphQL. Estos datos indexados permiten mostrar carteras, historiales de transacciones, paneles de análisis y funciones de búsqueda.
Los contratos inteligentes son la lógica en cadena de la aplicación. Definen las reglas para las transferencias de tokens, las operaciones de DeFi, la acuñación de NFT, las votaciones de gobernanza y cualquier otro comportamiento programable en cadena. Los contratos inteligentes se implementan una sola vez y se ejecutan de forma determinista cada vez que se invocan. Son la «lógica de backend» que reside en la cadena de bloques, en lugar de en el servidor de una empresa.
¿Cuáles son los componentes fundamentales de la infraestructura de la Web3?
Aunque las arquitecturas varían, la mayoría de las dapps en producción se basan en el mismo conjunto de componentes básicos. En la tabla siguiente se muestra la correspondencia entre cada capa, su función y un ejemplo habitual.
Capa
Función
Ejemplo
Cartera
Identidad del usuario y firma de transacciones
MetaMask, Phantom
Puntos finales RPC
Acceso de lectura y escritura a las cadenas
API de Quicknode
Indexadores
Hacer que los datos en cadena sean consultables
The Graph, Streams
Almacenamiento descentralizado
Almacena archivos de gran tamaño fuera de la cadena
IPFS, Arweave
Contratos inteligentes
Lógica de las aplicaciones en cadena
Contratos Solidity
Redes de capa 2
Aumenta el rendimiento y reduce las comisiones
Arbitrum, Base
Escalar capas como una red de capa 2, los contratos inteligentes que contienen tu lógica y un canal de procesamiento en tiempo real como Streams se integran en esta misma arquitectura.
Datos de lectura frente a datos de escritura
Las rutas de lectura y escritura en una dapp son fundamentalmente diferentes.
La lectura de datos es relativamente sencilla. El frontend (o backend) envía una solicitud RPC a un nodo solicitando datos específicos: un saldo, el estado de un contrato, el contenido de un bloque. El nodo busca la respuesta y la devuelve. En el caso de lecturas sencillas, este proceso de ida y vuelta tarda decenas de milisegundos con un buen proveedor. Para necesidades de datos complejas (como «muéstrame el historial completo de transacciones de este monedero para todos los tokens»), la dapp consulta la base de datos de un indexador en lugar de dirigirse directamente a la cadena de bloques, ya que el indexador ya se ha encargado de la parte más laboriosa: procesar y estructurar los datos.
La escritura de datos es más compleja. El usuario inicia una acción (como el intercambio de tokens). La dapp crea una transacción en la que se especifica el contrato inteligente al que se va a llamar, la función que se va a ejecutar y los parámetros que se van a pasar. La dapp calcula el coste del gas y se lo muestra al usuario. El usuario revisa y aprueba la transacción en su monedero, que la firma con su clave privada. La transacción firmada se envía a la red a través de un endpoint RPC. La transacción entra en el mempool y espera a que un validador la incluya en un bloque. Una vez incluida, la transacción queda confirmada. La dapp detecta la confirmación (ya sea mediante sondeo o a través de una suscripción WebSocket) y actualiza la interfaz de usuario para reflejar el nuevo estado.
Este proceso de escritura de varios pasos, en el que intervienen el monedero del usuario, la estimación del gas, la propagación por el mempool, la inclusión por parte de los validadores y la detección de la confirmación, es la razón por la que las operaciones de escritura en Web3 parecen más lentas que hacer clic en un botón en una aplicación tradicional. También es la razón por la que es fundamental contar con una infraestructura RPC fiable y de baja latencia: cada paso, desde la estimación del gas hasta el envío de la transacción y la detección de la confirmación, pasa por el endpoint RPC.
Realidad multicadena
Las dapps modernas rara vez funcionan en una sola cadena. Un protocolo DeFi puede implementarse enmainnet Ethereum , Arbitrum, Base, Optimism y Polygon. Un mercado de NFT puede ser compatible con Ethereum, Solana y múltiples L2. Una aplicación de monedero debe mostrar los saldos y permitir realizar transacciones en docenas de cadenas simultáneamente.
Esta realidad multicadena multiplica los requisitos de infraestructura. Cada cadena necesita sus propios puntos finales RPC, su propio proceso de indexación y su propio conocimiento de las particularidades específicas de cada cadena (diferentes modelos de finalidad, diferentes mecanismos de gas, diferentes formatos de transacción). Gestionar esta complejidad en 5, 10 o más de 80 cadenas supone un importante reto de ingeniería que la mayoría de los equipos resuelven recurriendo a un proveedor de infraestructura, en lugar de ejecutar sus propios nodos para cada cadena.
¿Es necesario ejecutar tu propio nodo para desarrollar una dapp?
En la mayoría de los casos, no. Puedes lanzar una dapp en producción utilizando un proveedor de RPC gestionado sin necesidad de gestionar nunca un nodo. Gestionar tu propio nodo te ofrece el máximo control y privacidad, pero también implica adquirir hardware, sincronizar cadenas, gestionar actualizaciones y bifurcaciones duras, y supervisar el tiempo de actividad las 24 horas del día para cada cadena que admitas. Por eso, a la hora de decidir entre «crear» o «comprar», los equipos que quieren centrarse en el producto en lugar de en las operaciones suelen decantarse por un proveedor. Si lo que quieres es tener un control total, en nuestra guía sobre cómo ejecutar tu propio nodo se analizan los costes y las ventajas.
Cómo Quicknode la infraestructura de la Web3
Quicknode la infraestructura básica de la que dependen las dapps. La API Core ofrece puntos finales RPC de nivel de producción en más de 80 redes blockchain desde una única plataforma, con nodos distribuidos por todo el mundo, un tiempo de actividad del 99,99 % y tiempos de respuesta 2,5 veces más rápidos que los de la competencia. Esto significa que los desarrolladores pueden dar soporte a múltiples cadenas sin tener que gestionar una infraestructura de nodos independiente para cada una de ellas.
Quicknode Streams la infraestructura de indexación personalizada por un canal de datos basado en envíos que entrega datos filtrados de la cadena de bloques directamente a tu base de datos o almacén, con entrega garantizada y gestión automática de la reorganización. En lugar de crear y mantener scripts de sondeo para cada cadena, solo tienes que configurar un Stream y Quicknode la extracción, el filtrado, la entrega y la coherencia de los datos.
En lo que respecta al conjunto más amplio de dapps, Quicknode IPFS y «pinning» para el almacenamiento descentralizado, complementos de Marketplace para mejorar las API (saldos de tokens, datos de NFT, análisis de DeFi) y elSDK Quicknode SDK una integración optimizada en JavaScript y TypeScript. En conjunto, estas herramientas proporcionan una plataforma de infraestructura completa para crear, escalar y gestionar aplicaciones Web3 en producción.
Preguntas frecuentes
¿Cuál es la diferencia entre un endpoint RPC endpoint un indexador?
Un endpoint RPC endpoint consultas directas sobre el estado actual de la cadena, como el saldo o una transacción concreta. Un indexador procesa todo el historial y lo almacena en una base de datos para que puedas realizar consultas complejas, como el historial completo de transacciones de un monedero, que el RPC por sí solo no puede gestionar de forma eficiente.
¿Puede funcionar una dapp sin un backend?
Sí. Muchas dapps funcionan íntegramente en el lado del cliente: la interfaz de usuario se comunica directamente con los puntos finales RPC y con el monedero del usuario. El backend es opcional y se añade para tareas fuera de la cadena, como el almacenamiento en caché, el análisis de datos y las transacciones sin gas.
¿Cómo se autentica un usuario en una aplicación Web3?
Los usuarios conectan un monedero en lugar de crear una cuenta. La dirección del monedero actúa como identidad, y la firma de un mensaje o una transacción demuestra el control sobre dicha dirección, sustituyendo así a los nombres de usuario y las contraseñas.
¿Por qué la mayoría de los equipos recurren a un proveedor de infraestructura?
Para dar soporte a numerosas cadenas de forma fiable, es necesario poner en marcha y mantener nodos, indexadores y sistemas de almacenamiento para cada una de ellas. Un proveedor consolida todo esto en una única plataforma, cuya implantación es más rápida y cuyo funcionamiento resulta más económico que desarrollarla internamente.
¿Está la infraestructura de Web3 totalmente descentralizada?
En parte sí, y en parte no. Las cadenas de bloques y los contratos inteligentes están descentralizados, pero los servicios de apoyo, como los proveedores de RPC y las interfaces de usuario, suelen ejecutarse en plataformas en la nube centralizadas. Las fuentes de datos en tiempo real, como la transmisión de datos de la cadena de bloques, también suelen proceder de proveedores gestionados.
