Santiant
← Casos técnicos
Blockchain Solidity Smart Contracts React Web3 JavaScript

dApp blockchain: smart contracts en Solidity, arquitectura on-chain/off-chain y frontend React

Diseño y desarrollo completo de una aplicación descentralizada sobre blockchain pública: smart contracts en Solidity, capa de abstracción Web3 y frontend React con gestión explícita del ciclo de vida de transacciones.

S
Santiago Moreno Arce ·

dApp blockchain: smart contracts, arquitectura on-chain/off-chain y frontend React

Resumen

Un cliente con una idea clara para una aplicación descentralizada necesitaba pasar del concepto a una implementación real. Se diseñó y construyó la solución completa: smart contracts en Solidity, arquitectura on-chain/off-chain, frontend en React y una capa de abstracción que aísla la aplicación de los detalles del proveedor Web3. Antes de comenzar el desarrollo se plantearon tres modalidades de alcance; la seleccionada multiplicó aproximadamente por tres el valor funcional respecto a la idea original sin incrementar desproporcionadamente el esfuerzo.

Contexto

El cliente operaba en el entorno Web3 con una propuesta basada en smart contracts sobre blockchain pública. La idea estaba definida desde el lado de negocio pero aún no tenía una arquitectura técnica: no estaba claro qué lógica debía ejecutarse on-chain, qué datos debían quedar off-chain, ni cómo debía estructurarse el modelo de contratos para ser mantenible y evitar costes innecesarios de gas.

El proyecto arrancaba desde cero, lo que permitía tomar esas decisiones desde el principio y no arrastrarlas como deuda.

Problema técnico

  • Sin una separación clara on-chain/off-chain, la aplicación acumularía costes de gas innecesarios y contratos difíciles de modificar.
  • Los contratos mal estructurados en blockchain no se pueden remendar después del despliegue: los errores de diseño tienen consecuencias permanentes.
  • El frontend necesitaba manejar correctamente el ciclo de vida de las transacciones (enviada, pendiente, confirmada, revertida) sin acoplar esa lógica a cada componente.
  • La integración directa con un proveedor Web3 concreto habría atado la aplicación a esa dependencia sin posibilidad práctica de cambio.

Lo que se construyó

Smart contracts en Solidity

Se diseñaron los contratos con responsabilidades acotadas y separación entre lógica de negocio y almacenamiento de estado. Las decisiones de diseño principales:

  • Superficie on-chain mínima: solo lo que necesita las garantías de inmutabilidad o descentralización va on-chain. Todo lo operativo, dinámico o fácil de modificar queda off-chain.
  • Patrones estándar: control de acceso por roles, eventos para trazabilidad, validaciones explícitas en cada función. Sin reinventar lo que la comunidad ya tiene probado.
  • Trazabilidad por eventos: los events emitidos por los contratos permiten reconstruir el historial completo sin depender de almacenamiento externo, lo que simplifica auditoría y reduce superficie de fallo.

Pruebas de contratos

Se cubrieron casos felices, escenarios de error esperados y condiciones de borde: valores límite, llamadas desde cuentas sin permiso, intentos de reentrada. En un entorno donde los fallos se pagan en dinero real y los contratos no se parchean, las pruebas no son opcionales.

Frontend en React

  • Capa de abstracción sobre Web3 que aísla al resto de la aplicación del proveedor concreto. Cambiar de proveedor o de red no exige reescribir los componentes.
  • Gestión explícita de estados intermedios de transacción: enviada, pendiente de confirmación, confirmada, fallida. La latencia y los reverts son parte normal del flujo en blockchain; la UI los refleja de forma clara en lugar de ignorarlos.
  • Separación entre estado de contrato (on-chain, leído por eventos y llamadas de lectura) y estado de interfaz (local, efímero).

Decisiones y trade-offs

Se descartó mover lógica compleja on-chain solo porque fuera técnicamente posible. Los contratos desplegados son difíciles de modificar; cada función on-chain tiene un coste operativo permanente. La pregunta en cada decisión fue: ¿necesita esto las garantías de la cadena, o es más barato y flexible gestionarlo off-chain?

Se priorizaron patrones ya auditados y probados por la comunidad sobre implementaciones propias. En blockchain, la originalidad en los contratos es un riesgo, no un mérito.

En el frontend se asumió algo más de complejidad inicial al añadir la capa de abstracción, a cambio de flexibilidad real a largo plazo.

Resultado

  • Aplicación desplegada y funcional, con contratos mantenibles y trazabilidad real de operaciones.
  • Arquitectura on-chain/off-chain clara, justificada decisión a decisión, sin estado innecesario en la cadena.
  • Frontend con gestión correcta del ciclo de vida de transacciones, preparado para manejar los comportamientos propios de blockchain sin sorpresas para el usuario.
  • Base preparada para evolucionar el producto: añadir funcionalidades no requiere rediseñar lo construido.
  • El cliente terminó el proyecto con criterio técnico propio para tomar decisiones futuras.

Stack técnico

  • Solidity
  • Smart contracts
  • JavaScript
  • React
  • Web3 (capa de abstracción frontend ↔ contratos)

Qué demuestra este caso

Capacidad para diseñar y construir una aplicación blockchain de principio a fin: desde las decisiones de arquitectura on-chain/off-chain hasta los contratos en Solidity, las pruebas y el frontend. No solo ejecutar lo que llega definido, sino proponer la estructura técnica correcta antes de escribir la primera línea de código, sabiendo que en blockchain las decisiones iniciales son las que más pesan.


¿Estás construyendo una aplicación blockchain o necesitas revisar el diseño de tus contratos antes de desplegar? Puedo ayudarte a definir la arquitectura y llevar el desarrollo.