Cómo crear una dApp: arquitectura, contratos y despliegue

Una aplicación descentralizada, o dApp, permite utilizar funciones de una red blockchain desde una interfaz. El usuario puede consultar información, conectar su wallet o solicitar una operación, mientras los contratos inteligentes ejecutan las reglas que corresponden a la red. Construir esa experiencia requiere conectar la aplicación con los contratos y con los servicios que necesita para funcionar.

El diseño empieza por decidir qué parte del proceso debe poder verificarse en blockchain y qué conservará la aplicación fuera de ella. Esa separación ayuda a definir los permisos del usuario y a mostrarle qué ocurre antes, durante y después de una transacción.

1. Define la operación que necesita verificación compartida

Elige un recorrido concreto: registrar una evidencia, transferir un activo o ejecutar una regla entre participantes. Identifica quién puede iniciarlo, qué resultado espera y qué debe poder comprobar otra parte. Compara ese objetivo con una aplicación convencional antes de asumir el coste de una cadena.

La introducción a dApps de Ethereum describe la combinación de frontend y contratos. En un producto real también pueden intervenir indexadores, almacenamiento y servidores. Documentar esas dependencias permite explicar qué funciones siguen disponibles si un proveedor falla.

2. Separa contrato, interfaz y backend

El contrato mantiene reglas y estado que deben compartirse. La interfaz prepara solicitudes y explica sus consecuencias. Un backend puede atender búsquedas, notificaciones o información privada. No debe convertirse silenciosamente en la única fuente de verdad de una propiedad que se presenta como verificable on-chain.

Un ejemplo sencillo es un registro de documentos: el archivo permanece en un almacén con permisos y la cadena registra una huella y su autor. Esto ayuda a comprobar una coincidencia posterior; no demuestra que el documento original fuera verdadero ni que su firmante tuviera atribuciones legales.

3. Elige la red y las bibliotecas

Valora finalidad, comisiones, permisos, wallets disponibles y capacidades del equipo. Si se usan puentes o una capa adicional, incorpora sus supuestos de seguridad. Para redes EVM, bibliotecas como viem permiten interactuar con contratos, con funciones para leer estado y preparar operaciones.

Fija versiones y prueba con las wallets del público real. La compatibilidad nominal no sustituye una prueba de conexión, cambio de cuenta, rechazo de firma y envío de transacciones. La interfaz debe mostrar la red y la operación que el usuario está autorizando.

4. Especifica permisos e invariantes antes de programar

Define quién puede administrar, pausar o actualizar contratos y qué límites afectan a cada rol. Una invariante expresa una propiedad que siempre debe mantenerse, como que una retirada no exceda el saldo disponible.

La guía de pruebas de contratos de Ethereum distingue técnicas complementarias. Usa pruebas unitarias, de integración y de propiedades donde aporten evidencia. Incluye actores no autorizados, respuestas inesperadas y fallos de dependencias; comprobar solo el recorrido correcto deja fuera los casos más útiles.

5. Diseña los estados de la transacción

• Preparada: la persona puede revisar destinatario, importe y permisos.
• Pendiente de firma: puede aceptar o rechazar sin perder el contexto.
• Enviada: la interfaz conserva una referencia verificable y evita duplicados.
• Confirmada o fallida: se comunica el resultado y el siguiente paso disponible.

No muestres como definitiva una operación que aún espera confirmación. Tampoco guardes claves privadas en el frontend o en logs. La gestión de claves, la configuración del nodo y los límites del servidor requieren revisión junto a los contratos.

Ejemplo de integración: registrar una evidencia sin duplicarla

Imaginemos una dApp que registra la huella de un documento. El usuario selecciona el archivo, revisa la operación y firma. Si cierra la pestaña después del envío, al volver debe poder recuperar el estado de esa solicitud. Mostrar otra vez el formulario vacío y sugerir un nuevo envío puede generar dos registros para una misma intención.

El diseño necesita relacionar la solicitud de negocio con la referencia de transacción y el resultado observado en la red. Si el proveedor RPC deja de responder, la aplicación debe comunicar que no puede consultar el estado, sin afirmar que la operación ha fallado. Un fallo de consulta y un rechazo del contrato requieren acciones diferentes.

La prueba de aceptación recorre ambos casos: respuesta perdida después del envío y transacción efectivamente rechazada. También comprueba que otro participante puede verificar la huella registrada y que la aplicación conserva el archivo con los permisos previstos. Es un ejemplo de implementación; registrar una huella no resuelve por sí solo la autenticidad jurídica del documento.

Este recorrido permite delimitar qué se audita en el contrato y qué se prueba en la integración. La experiencia depende de ambas partes, especialmente cuando la operación tarda más de lo esperado o el usuario cambia de dispositivo.

6. Despliega una versión identificable y prepara su operación

Mantén trazabilidad entre repositorio, pruebas, informe de auditoría y direcciones publicadas. Si el sistema es actualizable, explica las facultades del administrador y comprueba el procedimiento. Un usuario debería poder entender qué reglas pueden cambiar.

Después del lanzamiento hacen falta monitorización, gestión de incidencias y mantenimiento de integraciones. En Metlabs, el desarrollo de aplicaciones blockchain reúne esas piezas para entregar un producto operable, con límites y responsabilidades documentados.