¿Qué es una DApp?

Una aplicación descentralizada (decentralized application, DApp) es una aplicación que entrega parte de sus reglas o de su estado esenciales —por ejemplo saldos, titularidad y registros de autorización— a una red descentralizada como una blockchain, para que los ejecute y los conserve. Normalmente las personas siguen operando a través de una interfaz web o móvil, pero los resultados clave pueden ser validados por varios participantes de la red con reglas comunes, en lugar de depender solo de una base de datos del operador de la aplicación.

«Descentralizado» describe cómo se distribuyen el control y las dependencias de una aplicación; no es una etiqueta que se obtenga de forma automática. Una DApp puede ejecutar sus contratos principales en cadena y al mismo tiempo depender de un único sitio web, de una interfaz de datos, de una clave de administración o de un servidor fuera de la cadena. Por eso, juzgar una DApp implica revisar capa por capa de qué está hecha y quién controla cada capa.

De qué se compone habitualmente una DApp

Una DApp normalmente no es un contrato inteligente aislado, sino una experiencia completa que entregan varios componentes en conjunto:

• Interfaz de usuario: aplicación web o móvil que muestra información y recibe acciones;
• Billetera: guarda o invoca la capacidad de firma de la persona, que así confirma conexiones de cuenta y transacciones;
• Programas en cadena: contratos inteligentes o programas de la red que procesan transferencias, autorizaciones y actualizaciones de estado según su código;
• Servicios de conexión a la red: envían consultas y transacciones firmadas a los nodos de la blockchain;
• Servicios fuera de la cadena: pueden encargarse de búsqueda, indexación, notificaciones, almacenamiento de imágenes o suministro de datos externos.

La introducción a las DApps de Ethereum considera los contratos inteligentes y una interfaz frontal como la combinación habitual. Otras redes pueden usar modelos distintos de programas y cuentas. Solana, por ejemplo, separa los programas ejecutables de las cuentas que guardan datos modificables. Las implementaciones difieren, pero quien lee puede revisar una aplicación con las mismas preguntas: interfaz, autorización, ejecución por la red y procedencia de los datos.

Las etapas principales de una operación

Después de abrir una DApp, la interfaz puede primero leer información pública —un saldo, una cotización o un registro concreto en cadena— mediante un nodo o mediante un servicio de indexación (un indexador) que organiza los datos en cadena para poder consultarlos. Estas lecturas normalmente no cambian el estado de la blockchain y no requieren que la persona firme cada consulta; lo que se muestra igual depende de los datos que devuelve el servicio conectado y del momento de la consulta.

Cuando la persona inicia una operación que cambiará el estado, la DApp construye una solicitud de transacción y la entrega a la billetera. La billetera debería mostrar la red, la dirección de destino, qué se está autorizando y las comisiones que pueden surgir; tras la confirmación, firma la transacción con la capacidad de firma de la cuenta correspondiente.

La transacción firmada se envía después a los nodos de la blockchain. Los nodos revisan la firma y el formato de la transacción según el protocolo, y ejecutan el programa de destino al construir o validar un bloque candidato. Cuando la transacción queda incluida en un bloque válido, el resultado de la ejecución pasa a ser parte del estado de esa cadena y otros nodos pueden recalcularlo y leerlo. Si la ejecución falla, la interfaz también debería actualizarse según el resultado real de la transacción, en lugar de mostrar solo que envió una solicitud.

Entrar en un bloque válido no equivale necesariamente a una confirmación final inmediata. Una transacción todavía puede necesitar más confirmaciones, y en ciertas condiciones de red el historial de bloques también puede reorganizarse. Cuándo algo puede considerarse definitivo depende del mecanismo de consenso de la red concreta.

Este proceso muestra que la propia página web normalmente no modifica la blockchain de forma directa. La interfaz prepara y muestra solicitudes, la billetera se encarga de la autorización de la persona, y la red junto con los programas en cadena determinan si el estado cambia conforme a las reglas.

Conectar la billetera no es aprobar una transacción

Conectar una billetera normalmente solo permite que la DApp sepa qué dirección pública eligió la persona, y le abre un canal para enviar solicitudes a la billetera. Qué cuentas puede ver la aplicación y qué solicitudes puede hacer dependen de la billetera y del estándar de conexión que se use. Conectar no debería equivaler a entregar una clave privada, y tampoco significa que la persona haya aprobado ninguna transferencia de activos.

Las solicitudes posteriores pueden cumplir funciones distintas:

• Firmar un mensaje: demuestra que la cuenta firmó un texto o dato específico, sin producir necesariamente una transacción en cadena;
• Enviar una transacción: pide a la red ejecutar una transferencia o una llamada a contrato;
• Autorización de tokens: permite que una dirección o un programa mueva tokens dentro de un alcance definido;
• Cambiar de red: hace que la billetera pase a otra blockchain o a una red de prueba.

Las personas necesitan ver con claridad el contenido real de cada solicitud. Desconectarse de un sitio normalmente solo cierra la sesión actual; no revoca de forma automática las autorizaciones de tokens u otros permisos ya escritos en cadena.

Reglas en cadena e interfaces fuera de la cadena

Lo que manejan los programas en cadena puede ser revisado en conjunto por los participantes de la red, pero la página web que ve la persona puede seguir alojada por un equipo determinado. Un sitio puede actualizarse, cerrarse, restringir el acceso o mostrar información equivocada, mientras un contrato ya desplegado puede continuar existiendo.

Que un contrato siga en cadena no significa que las personas comunes puedan seguir usándolo con comodidad. También hacen falta una interfaz que funcione, la dirección de contrato correcta, una conexión a un nodo y la interpretación necesaria de los datos. Quienes tienen soltura técnica pueden usar otra interfaz o llamar al contrato directamente, pero eso depende de que el contrato exponga un punto de entrada adecuado y aumenta la dificultad de la operación.

A la inversa, una interfaz con código fuente abierto u alojamiento distribuido no permite establecer que el programa en cadena no tenga permisos de administración. Evaluar una estructura de control implica revisar por separado la forma de publicación del frontend, los derechos de actualización de contratos, los derechos de pausa, los permisos sobre fondos y las dependencias externas.

No todos los datos se almacenan necesariamente en cadena

Una blockchain es adecuada para el estado que necesita validación conjunta, pero almacenar directamente grandes volúmenes de imágenes, video o datos de búsqueda puede resultar costoso. Por eso las DApps suelen mantener en cadena los saldos y permisos esenciales, y colocar el resto del contenido en servidores comunes o redes de archivos distribuidas.

Tomemos el InterPlanetary File System (IPFS), un protocolo de archivos distribuido que localiza los datos por su contenido y no por una ubicación fija de servidor. IPFS genera para el contenido un identificador de datos verificable. Eso ayuda a quien lee a revisar si el contenido recibido coincide con el identificador, pero no garantiza que siempre haya alguien en línea sirviendo el archivo, ni establece que su contenido sea verdadero.

Registrar en cadena un enlace web o un identificador de contenido solo establece que la aplicación guardó esa referencia. Si el destino del enlace es accesible, quién lo mantiene, si puede reemplazarse y cuánto tiempo se conserva son puntos que igual deben revisarse en el esquema concreto.

El grado de descentralización hay que juzgarlo por capas

En lugar de preguntar si una DApp está «totalmente descentralizada», es más útil revisar cada capa:

• Ejecución: ¿las reglas principales las ejecutan en conjunto varios nodos, o las decide un solo servidor?
• Estado: ¿dónde están los saldos y permisos clave, y quién puede modificarlos?
• Actualizaciones: ¿los contratos se pueden actualizar, y qué aprobación exige una actualización?
• Interfaz: ¿hay solo un punto de entrada oficial, y otras personas pueden desplegar una alternativa?
• Datos: ¿la aplicación depende de un único servicio de nodo, indexador, oráculo o servidor de archivos?
• Gobernanza: ¿quién responde por la pausa, el ajuste de parámetros y la gestión de fondos?

Respuestas distintas producen estructuras de control distintas. Exigir que varios participantes firmen en conjunto, fijar un período de espera antes de que un cambio surta efecto, o decidir mediante una votación pública reparten cada uno parte de los permisos sin eliminar de forma automática toda dependencia concentrada; del mismo modo, conservar una pausa de emergencia puede ser una decisión deliberada de control de riesgos. Un artículo debe describir el esquema real en lugar de concluir a partir del nombre «DApp».

En qué se diferencia una DApp de una aplicación común

Los dos tipos de aplicación pueden tener páginas web, cuentas y servicios de backend. La diferencia está sobre todo en quién confirma el estado y las reglas clave.

Una aplicación común normalmente hace que los servidores del operador reciban las solicitudes, modifiquen una base de datos y decidan la versión del software. Las personas tienen que confiar en que el operador guarde los datos correctamente, y por lo general solo pueden llegar al servicio por las interfaces que el operador provee.

Una DApp puede colocar parte de las reglas y del estado en una red blockchain, para que los nodos las ejecuten según el protocolo. Las personas firman transacciones con sus propias cuentas, y otras interfaces pueden llamar a los mismos programas en cadena. Esa verificabilidad, sin embargo, viene con compensaciones: comisiones, estado público, espera de confirmación, fallas de contrato y coordinación de actualizaciones.

Por eso una DApp no es «una aplicación que no necesita equipo de desarrollo ni servidores». Mueve ciertas decisiones de un backend único a una red común, y al mismo tiempo puede conservar componentes fuera de la cadena.

DApps, contratos inteligentes y organizaciones en cadena

Un contrato inteligente es código que se ejecuta en cadena; una DApp es la aplicación completa de cara a las personas, que normalmente incluye contratos inteligentes, una interfaz y otros servicios. Un contrato puede ser usado por varias DApps, y una DApp puede llamar a varios contratos.

Una organización autónoma descentralizada (decentralized autonomous organization, DAO) es una forma de organizarse que usa reglas en cadena, votaciones o permisos de varias partes para coordinar decisiones y recursos. Una DAO puede ofrecer una interfaz de votación a través de una DApp, pero una DApp no es necesariamente una DAO y no tiene que emitir un token de gobernanza.

De igual modo, que una aplicación tenga un token no la vuelve descentralizada de forma automática. La distribución del token, los permisos de administración, las actualizaciones de contratos y el control de la interfaz igual deben revisarse por separado.

Principales límites y riesgos

Los riesgos de una DApp pueden venir de cada capa:

• el código del contrato inteligente tiene fallas, o los permisos de administración exceden lo que las personas esperan;
• la interfaz es alterada e induce a firmar una transacción equivocada;
• la billetera no muestra con claridad qué se está llamando;
• un nodo o servicio de indexación devuelve datos desactualizados, equivocados o incompletos;
• un servicio que envía información externa a la cadena entrega datos inexactos;
• archivos, nombres de dominio o el punto de entrada oficial dejan de funcionar;
• la red base se congestiona, cambian sus comisiones o sufre una falla.

Que una transacción se ejecute con éxito en una blockchain solo muestra que cumplía las reglas de la red y del contrato en ese momento. No establece que la persona haya entendido la solicitud, ni que la información fuera de la cadena que entregó la aplicación fuera verdadera.

Preguntas frecuentes

¿Una DApp debe tener su propio token?

No. Un token puede servir para pagos, permisos o gobernanza, pero no es una condición necesaria para que algo sea una DApp.

¿Todos los datos de una DApp son públicos?

No necesariamente. Las transacciones y el estado en una blockchain pública normalmente se pueden leer, pero una aplicación también puede usar bases de datos fuera de la cadena, datos cifrados o técnicas de privacidad. Lo que realmente queda visible depende de la red y del diseño.

¿Se puede seguir usando una DApp después de que cierre su sitio oficial?

Los programas en cadena pueden seguir existiendo, pero también hacen falta una interfaz alternativa, una conexión a un nodo y la información de contrato correcta. Que el uso pueda continuar depende de que cada componente esté abierto y disponible.

¿Al usar una DApp se le entrega la clave privada al sitio?

Una interacción normal con la billetera no requiere entregar la clave privada a un sitio. La billetera firma dentro de su propio límite de seguridad y luego entrega la firma o la transacción firmada a la aplicación. Igual conviene desconfiar de interfaces que piden una frase de recuperación o una clave privada, o que empujan a firmar solicitudes peligrosas.

¿Una DApp necesariamente no tiene administrador?

No necesariamente. Un contrato puede conservar permisos de actualización, pausa, ajuste de parámetros o gestión de fondos. Hay que revisar el código y los permisos concretos en lugar de guiarse por el nombre de la aplicación.

Conceptos relacionados

Continúa con contrato inteligente, Ethereum, la EVM, billetera no custodial y blockchain, o vuelve al glosario de criptomonedas.

Fuentes

• Ethereum.org: introducción a las dapps — relación básica entre un frontend, los contratos inteligentes y una red descentralizada.
• Ethereum.org: introducción a los contratos inteligentes — despliegue, llamadas y límites de ejecución de los programas en cadena.
• IPFS Docs: how IPFS works — direccionamiento por contenido, identificadores de datos, enrutamiento y transferencia de archivos.
• Solana Docs: programs — ejemplo de implementación que separa programas ejecutables de cuentas de datos independientes.