Embark Framework

¿Qué es Embark Framework?

Embark Framework es un framework de desarrollo de código abierto creado para ayudar a los desarrolladores a crear, probar, desplegar y gestionar aplicaciones descentralizadas.

Se diseñó principalmente para aplicaciones que utilizan contratos inteligentes de Ethereum Virtual Machine, interfaces web, almacenamiento descentralizado y tecnologías de comunicación entre pares.

El repositorio oficial de Embark Framework lo describe como un framework para desarrollar y desplegar aplicaciones descentralizadas.

Embark automatizaba muchas tareas que, de otro modo, los desarrolladores habrían tenido que realizar manualmente.

Entre ellas se incluían compilar contratos inteligentes, determinar el orden de despliegue, desplegar contratos, registrar las direcciones desplegadas, regenerar los artefactos del frontend, ejecutar pruebas, iniciar servicios blockchain locales y publicar los archivos de la aplicación.

El framework destacaba especialmente porque intentaba gestionar toda la pila de la aplicación descentralizada, en lugar de centrarse únicamente en la compilación de contratos inteligentes.

Un proyecto de Embark podía combinar contratos blockchain, código de aplicación JavaScript, almacenamiento descentralizado de archivos, servicios de nombres y mensajería descentralizada mediante un flujo de trabajo basado en la configuración.

Embark fue una herramienta importante para el desarrollo de Ethereum durante las primeras fases de crecimiento de las aplicaciones descentralizadas.

Sin embargo, su última versión estable se publicó en abril de 2020. Actualmente, los desarrolladores deben considerarlo software heredado que puede requerir un trabajo considerable de compatibilidad y seguridad.

¿Para qué se diseñó Embark?

Embark se diseñó para reducir el trabajo de configuración y coordinación necesario para desarrollar aplicaciones descentralizadas.

Una aplicación descentralizada suele incluir varios componentes que deben funcionar correctamente en conjunto.

Puede contener contratos de Solidity, un nodo blockchain, scripts de despliegue de contratos, interfaces binarias de aplicación generadas, bibliotecas JavaScript, una interfaz web, almacenamiento descentralizado, pruebas y configuración específica de cada red.

Sin un framework, los desarrolladores deben configurar y conectar cada componente por su cuenta.

Embark intentaba proporcionar un único entorno que reconociera esos componentes y los actualizara a medida que cambiaba el proyecto.

Por ejemplo, un cambio en un contrato de Solidity podía hacer que Embark lo recompilara, determinara si debía volver a desplegarse, actualizara la dirección del contrato, regenerara los artefactos del frontend y reconstruyera la aplicación.

Este flujo de trabajo automatizado pretendía acortar los ciclos de desarrollo y reducir los errores de configuración manual.

¿Se sigue manteniendo Embark Framework?

Embark debe considerarse un framework de desarrollo cripto heredado, no una opción con mantenimiento activo para un nuevo proyecto de producción.

El repositorio oficial identifica la versión 6.0.0, publicada el 27 de abril de 2020, como su última versión estable.

El registro oficial de cambios recoge dos compilaciones nightly posteriores, fechadas el 8 de agosto de 2020 y el 8 de octubre de 2020.

El registro público del paquete Embark también muestra que el paquete principal no ha tenido una publicación estable reciente.

La guía actual de frameworks de desarrollo de Ethereum explica la función de los frameworks full-stack, pero ya no incluye Embark entre los frameworks enumerados.

La falta de versiones recientes implica que las dependencias antiguas, los sistemas de compilación, los clientes blockchain, las API de JavaScript y las suposiciones sobre las redes podrían no funcionar de forma segura en un equipo de desarrollo actual.

Los proyectos existentes de Embark aún pueden contener código, contratos, pruebas e historial de despliegues útiles.

Sin embargo, los equipos que los mantengan deben auditar todas las dependencias y plantearse migrar los flujos de trabajo críticos a componentes con mantenimiento activo.

¿Quién creó Embark?

Embark fue creado originalmente por el desarrollador Iuri Matias y, más adelante, desarrollado por un equipo más amplio de código abierto.

El proyecto pasó por distintas organizaciones de GitHub a medida que cambiaban sus responsables de mantenimiento y el apoyo organizativo.

Su código fuente público principal se encuentra ahora en la organización Embark Labs de GitHub.

El repositorio contiene miles de commits históricos y numerosos paquetes modulares para interacción con blockchain, despliegue, pruebas, almacenamiento, comunicación, generación de código y herramientas de interfaz de usuario.

Embark se publicó con licencia MIT, que permite estudiar, modificar y redistribuir el código conforme a las condiciones de la licencia.

¿Qué es un framework de desarrollo de DApps?

Un framework de desarrollo de aplicaciones descentralizadas es un conjunto de herramientas que coordina tareas habituales de desarrollo blockchain.

La documentación de desarrollo de Ethereum explica que los frameworks suelen incluir herramientas blockchain locales, compilación de contratos, pruebas, integraciones de frontend, configuración de redes, despliegue y compatibilidad con la distribución descentralizada.

Un framework no sustituye los conocimientos sobre contratos inteligentes ni sobre seguridad blockchain.

Automatiza partes del proceso de desarrollo.

El framework puede generar la configuración, pero el desarrollador sigue siendo responsable de comprender qué hacen el código generado y las transacciones.

Usar un framework de desarrollo puede mejorar la productividad, pero también introduce dependencias y suposiciones específicas del framework.

¿Qué significaba «serverless» en Embark?

Embark describía con frecuencia las aplicaciones descentralizadas como aplicaciones HTML5 serverless que utilizaban una o más tecnologías descentralizadas.

En este contexto, serverless no significaba necesariamente que no hubiera servidores ni ordenadores.

Los nodos blockchain, los pares de almacenamiento, las pasarelas, los servicios de wallet y la infraestructura de distribución web seguían teniendo que ejecutarse en algún lugar.

El término indicaba que la aplicación podía reducir su dependencia de un único servidor de aplicaciones tradicional controlado por un solo operador.

Los contratos inteligentes podían albergar lógica y estado compartidos de la aplicación.

El almacenamiento descentralizado podía distribuir archivos entre nodos participantes.

Un frontend estático podía comunicarse directamente con servicios de blockchain o almacenamiento desde el navegador del usuario.

Muchas aplicaciones reales seguían utilizando servicios centralizados para indexación, analítica, notificaciones, atención al usuario, caché, autenticación o una entrega de datos más rápida.

Gestión de contratos inteligentes en Embark

La gestión de contratos inteligentes era una de las principales funciones de Embark.

El framework podía localizar los archivos de código fuente de los contratos, compilarlos, determinar sus dependencias y desplegarlos en una red EVM configurada.

Registraba qué contratos ya se habían desplegado e intentaba evitar despliegues innecesarios.

Si un contrato dependía de la dirección de otro, Embark podía organizar el orden de despliegue y pasar la dirección necesaria al contrato dependiente.

Esto resultaba útil para aplicaciones con contratos de tokens, registros, controles de acceso, fábricas, bibliotecas y otros componentes vinculados.

El sistema también generaba artefactos de contrato que el código JavaScript podía utilizar para llamar a los contratos desplegados.

El despliegue automatizado reducía el trabajo repetitivo, pero los desarrolladores aún debían confirmar los argumentos del constructor, las direcciones con privilegios, los ID de red, la configuración de gas y las cuentas de despliegue.

Redespliegue automático de contratos

Embark podía supervisar los archivos de contratos inteligentes mientras el entorno de desarrollo estaba activo.

Cuando cambiaba un contrato, el framework podía recompilarlo y determinar si era necesario desplegarlo de nuevo.

A continuación, podía actualizar los artefactos de la aplicación y reconstruir el frontend.

Esto aceleraba el ciclo de desarrollo, ya que el desarrollador no tenía que repetir cada comando manualmente.

El redespliegue automático resultaba principalmente práctico en redes locales o de desarrollo desechables.

Redesplegar un contrato de producción crea una nueva dirección y no traslada automáticamente el estado ni los activos del contrato original.

Un desarrollador nunca debe tratar un redespliegue de producción como si fuera una simple actualización de una aplicación web.

Los contratos inmutables y los sistemas actualizables requieren procedimientos diferentes de migración, gobernanza y seguridad.

Configuración de contratos

Los proyectos de Embark utilizaban archivos de configuración para describir los contratos y el comportamiento del despliegue.

Una configuración podía especificar si debía desplegarse un contrato, qué argumentos de constructor necesitaba, qué cuenta debía desplegarlo y de qué otros contratos dependía.

Se podían utilizar configuraciones de entorno distintas para desarrollo local, redes privadas, entornos públicos de pruebas y redes de producción.

Separar los entornos ayudaba a los equipos a evitar el uso de las mismas direcciones, credenciales o reglas de despliegue en todas partes.

Los archivos de configuración podían seguir siendo peligrosos si contenían claves privadas, frases de recuperación, contraseñas o endpoints remotos sin restricciones.

Las credenciales sensibles nunca deben incluirse en un repositorio público de código fuente.

EmbarkJS

EmbarkJS era la capa de integración JavaScript utilizada por las aplicaciones frontend creadas con Embark.

Permitía que el código del navegador accediera a contratos inteligentes desplegados y a otros servicios descentralizados configurados.

Embark generaba objetos de contrato basados en las interfaces binarias de aplicación compiladas y las direcciones de los contratos desplegados.

Los desarrolladores de frontend podían utilizar esos objetos para llamar a funciones de contrato de solo lectura, enviar transacciones y escuchar eventos blockchain.

EmbarkJS también proporcionaba módulos de integración para almacenamiento, comunicación y nombres cuando esas funciones estaban habilitadas.

Los objetos generados reducían la gestión manual de direcciones e ABI.

Sin embargo, el frontend seguía teniendo que gestionar el acceso a las cuentas, la selección de red, la confirmación de transacciones, las firmas rechazadas, las transacciones revertidas y los cambios en el estado de la blockchain.

Promesas de JavaScript y operaciones asíncronas

Embark exponía muchas operaciones de contratos mediante promesas de JavaScript.

Esto se ajustaba a la naturaleza asíncrona del desarrollo de aplicaciones blockchain.

Una llamada a un contrato puede requerir una solicitud RPC a un nodo remoto.

Una transacción que modifica el estado puede requerir la aprobación del usuario, su difusión, inclusión en un bloque y varias confirmaciones.

Los desarrolladores debían distinguir entre una transacción enviada y otra ejecutada correctamente y con suficientes confirmaciones.

Que se resolviera una promesa de envío no siempre significaba que la acción prevista del contrato hubiera tenido éxito.

Las aplicaciones debían revisar los recibos, el estado de ejecución, los eventos emitidos y la información de error.

Embark y las redes EVM

Embark se diseñó principalmente para Ethereum y otras blockchains compatibles con Ethereum Virtual Machine.

La EVM ejecuta bytecode de contratos inteligentes y proporciona un modelo común para cuentas, almacenamiento, mensajes, gas y llamadas a contratos.

Embark podía conectarse a nodos locales, redes privadas, entornos de pruebas o redes públicas mediante proveedores configurados.

Utilizaba métodos JSON-RPC compatibles con Ethereum para comunicarse con los nodos blockchain.

La documentación JSON-RPC de Ethereum describe la interfaz de solicitud estándar que utilizan las aplicaciones para consultar nodos y enviar transacciones.

Un framework puede admitir la interfaz RPC y, aun así, ser incompatible con tipos de transacción más recientes, mercados de comisiones, versiones de compiladores, parámetros de clientes o comportamientos de red.

Desarrollo blockchain local

Embark podía iniciar o conectarse a un entorno blockchain local para desarrollo y pruebas.

Una red local permitía desplegar contratos rápidamente sin gastar activos de redes públicas.

Podía proporcionar cuentas de prueba con saldos simulados y una producción de bloques más rápida.

El desarrollo local resultaba útil para comprobar la lógica de los contratos, la integración del frontend, el orden de despliegue y los flujos de transacciones.

Una blockchain local no reproducía todas las condiciones de una red pública.

Las redes reales incluyen comisiones variables, transacciones retrasadas, usuarios maliciosos, protocolos externos, precios cambiantes, congestión de red y comportamientos más complejos de reorganización o finalidad.

Los sistemas de producción requerían pruebas adicionales en entornos y con supuestos realistas.

Pruebas en Embark

Embark admitía el desarrollo basado en pruebas de contratos inteligentes mediante JavaScript.

Los desarrolladores podían escribir pruebas que desplegaran contratos, llamaran a funciones, enviaran transacciones y comprobaran el estado resultante.

El framework gestionaba las cuentas de prueba y podía restablecer o inicializar la blockchain de desarrollo para ejecutar las pruebas.

Las pruebas de contratos podían verificar el comportamiento del despliegue, los controles de acceso, los saldos de tokens, los eventos, las reversiones y las interacciones entre contratos.

Las pruebas automatizadas eran una de las funciones más valiosas de Embark, ya que los errores en contratos inteligentes pueden volverse permanentes después del despliegue.

Superar las pruebas no demostraba que un contrato fuera seguro.

Las pruebas solo cubrían los escenarios y supuestos incluidos por el desarrollador.

¿Qué deberían cubrir las pruebas de contratos inteligentes?

Una buena suite de pruebas debe incluir el comportamiento esperado de los usuarios y comportamientos deliberadamente hostiles.

Debe probar llamadas autorizadas y no autorizadas.

Debe probar valores cero y máximos, llamadas repetidas, órdenes inesperados, direcciones no válidas, llamadas externas fallidas y condiciones límite.

Debe comprobar que los cambios de estado sigan siendo correctos cuando una transacción se revierte.

Debe probar la reentrancia cuando el contrato envía activos o llama a contratos no fiables.

Debe probar las funciones administrativas, las vías de actualización, los controles de pausa, las retiradas de emergencia y las transferencias de propiedad.

La guía de seguridad de Solidity explica riesgos habituales, como la reentrancia, los bucles limitados por gas, los proxies autorizados, la información privada y las llamadas externas.

Artefactos de contratos de Embark

Un artefacto de contrato es un archivo generado que contiene la información necesaria para desplegar un contrato inteligente o interactuar con él.

Puede incluir la ABI, el bytecode, la dirección desplegada, información de red, la salida del compilador y referencias al código fuente.

Embark generaba artefactos para que el código del frontend y de pruebas pudiera acceder a los contratos sin copiar manualmente sus direcciones e interfaces.

Los artefactos debían corresponder a la red de despliegue prevista.

Usar una dirección de otra red podía hacer que una aplicación llamara a un contrato no relacionado o a una dirección sin código.

Las aplicaciones de producción deben verificar el ID de cadena de la blockchain y el bytecode del contrato, en lugar de confiar únicamente en un archivo de artefacto local.

Pipeline de compilación de Embark

Embark incluía un pipeline de compilación para preparar los recursos frontend de una aplicación descentralizada.

El pipeline podía copiar, transformar o agrupar JavaScript, HTML, hojas de estilo, imágenes y artefactos blockchain generados.

Podía trabajar con herramientas de desarrollo web y bibliotecas frontend habituales, sin exigir una única tecnología de interfaz.

Esta flexibilidad permitía a los desarrolladores mantener prácticas conocidas de desarrollo web y añadir integraciones blockchain.

Los pipelines de compilación conllevan riesgos para la cadena de suministro de software porque ejecutan paquetes y scripts durante la instalación o la compilación.

Un proyecto antiguo puede depender de paquetes obsoletos que contengan vulnerabilidades, ya no se instalen correctamente o hayan desaparecido de su fuente original.

Embark Cockpit

Embark incluía una interfaz gráfica de desarrollo conocida habitualmente como Cockpit.

Cockpit pretendía ofrecer a los desarrolladores una vista visual del entorno de aplicaciones descentralizadas en ejecución.

Podía mostrar contratos, transacciones, registros, procesos, servicios y el estado del desarrollo.

La interfaz también incluía herramientas para interactuar con contratos y explorar la actividad durante el desarrollo.

Un panel visual podía facilitar el uso del framework frente a varias ventanas de línea de comandos independientes.

Los desarrolladores seguían necesitando comprender las transacciones subyacentes, ya que un panel podía simplificar u omitir detalles importantes.

Hoy puede resultar especialmente difícil ejecutar los componentes históricos de Cockpit porque las dependencias frontend y el comportamiento de los navegadores han cambiado desde las últimas versiones.

Consola de Embark

La consola de Embark proporcionaba un entorno interactivo de comandos conectado a un proyecto configurado y a una red blockchain.

Los desarrolladores podían utilizarla para inspeccionar cuentas, acceder a objetos de contrato generados, llamar a funciones de lectura y enviar transacciones.

Una consola interactiva resultaba útil para depurar y realizar pruebas manuales.

También podía ser peligrosa si se conectaba a una cuenta de producción con activos valiosos.

Los comandos podían desplegar contratos, cambiar el estado, transferir activos o conceder permisos.

Las claves privadas y las cuentas desbloqueadas nunca deben exponerse mediante una consola no protegida o un endpoint RPC accesible públicamente.

Embark y el almacenamiento descentralizado

Embark se integraba con sistemas de almacenamiento descentralizado para que las aplicaciones pudieran cargar, recuperar y publicar archivos fuera de la blockchain.

Almacenar directamente archivos grandes de una aplicación en el almacenamiento de contratos EVM suele ser caro.

Una red de almacenamiento descentralizado puede guardar archivos frontend, imágenes, metadatos, documentos u otro contenido, mientras la blockchain conserva una referencia o identificador de contenido.

EmbarkJS proporcionaba una interfaz común para la aplicación para los servicios de almacenamiento compatibles.

Embark también podía desplegar el frontend estático de una aplicación mediante almacenamiento descentralizado.

Esto reducía la dependencia de un único servidor web tradicional, pero no garantizaba que el contenido estuviera disponible para siempre.

Embark e IPFS

IPFS era una de las principales integraciones de almacenamiento descentralizado de Embark.

IPFS utiliza direccionamiento por contenido: un archivo puede identificarse mediante una descripción criptográfica de su contenido, en lugar de únicamente por la ubicación de un servidor.

La documentación oficial de IPFS explica cómo los identificadores de contenido permiten solicitar datos según lo que contienen.

Modificar un archivo suele generar un identificador de contenido distinto.

Esto ayuda a detectar cambios en el contenido.

No garantiza automáticamente su disponibilidad, ya que al menos un participante accesible debe seguir almacenando y sirviendo los datos.

Los proyectos necesitan un plan de pinning, replicación o persistencia para los archivos importantes de la aplicación.

Embark y Swarm

Embark también incluía compatibilidad histórica con el almacenamiento y el despliegue de aplicaciones basado en Swarm.

El framework podía publicar archivos frontend y recuperar códigos fuente de contratos o contenido de aplicaciones mediante las integraciones de almacenamiento compatibles.

Las API de almacenamiento y el comportamiento de las redes han evolucionado desde la última versión estable de Embark.

Por tanto, una configuración antigua puede ser incompatible con los nodos, las pasarelas, las versiones de paquetes o las reglas de direccionamiento actuales.

Los desarrolladores que mantengan un proyecto histórico deben probar cada operación de almacenamiento por separado antes de confiar en ella en producción.

Comunicación descentralizada

Embark incluía integraciones para sistemas de comunicación descentralizados o entre pares.

La documentación del proyecto mencionaba Whisper y Orbit como tecnologías de comunicación compatibles.

Estas integraciones pretendían permitir que las aplicaciones descentralizadas enviaran y recibieran mensajes por canales sin depender por completo de un único servidor de mensajería convencional.

Una capa de comunicación podía admitir notificaciones, chat, coordinación o intercambio de datos específico de la aplicación.

La entrega de mensajes, la protección contra spam, la identidad, el cifrado, el acceso sin conexión y el almacenamiento a largo plazo seguían siendo problemas de diseño independientes.

Es posible que las integraciones históricas de comunicación ya no funcionen con el software de red actual.

Plugins de Embark

Embark utilizaba una arquitectura modular de plugins para ampliar sus funciones principales.

Los plugins podían añadir clientes blockchain, sistemas de almacenamiento, servicios de comunicación, compiladores, herramientas de pruebas, comportamiento de despliegue, comandos de consola o integraciones de aplicaciones.

El sistema de plugins hacía el framework más flexible, ya que los desarrolladores no tenían que modificar el proyecto principal para cada servicio nuevo.

Los plugins también aumentaban los riesgos de compatibilidad y de la cadena de suministro.

Un plugin podía ejecutar código local, leer la configuración, acceder a cuentas, modificar archivos generados o afectar al comportamiento del despliegue.

Antes de instalar un plugin, los desarrolladores deben revisar su código fuente, responsables de mantenimiento, historial de versiones, dependencias y permisos.

Comandos de Embark

Embark ofrecía comandos de línea de comandos para crear, ejecutar, probar, compilar e interactuar con proyectos.

El comando histórico de instalación era

.

El comando

podía crear una aplicación descentralizada de ejemplo.

El comando

iniciaba los servicios de desarrollo configurados y supervisaba los cambios del proyecto.

El comando

ejecutaba pruebas de contratos inteligentes.

El comando

preparaba los archivos de la aplicación para su despliegue.

El comando

abría un entorno interactivo conectado a una configuración seleccionada.

Estos comandos históricos pueden fallar en los sistemas operativos o entornos de paquetes actuales porque el software y sus dependencias son antiguos.

Configuración de entornos en Embark

Un proyecto de Embark podía definir distintos entornos para diferentes destinos blockchain.

Un entorno local podía utilizar cuentas generadas automáticamente y una blockchain simulada.

Un entorno público de pruebas podía conectarse a un nodo remoto y desplegar mediante una cuenta de prueba con fondos.

Un entorno de producción podía utilizar controles de firma más estrictos, direcciones de contrato fijas y una configuración de gas revisada cuidadosamente.

Separar los entornos reducía el riesgo de utilizar por error una configuración de pruebas en producción.

Sin embargo, los nombres de los entornos no proporcionaban seguridad por sí solos.

Los scripts de despliegue seguían necesitando comprobaciones explícitas del ID de cadena y procedimientos seguros de gestión de claves.

Embark y las dependencias entre contratos

Las aplicaciones descentralizadas grandes suelen contener contratos que dependen de otros contratos.

Un constructor puede necesitar la dirección de un token, un registro, una biblioteca, un administrador o un oráculo.

Embark permitía que la configuración del despliegue hiciera referencia a otros contratos y resolviera sus direcciones desplegadas.

Podía utilizar esta información de dependencias para determinar el orden de despliegue correcto.

La automatización de dependencias reducía la copia manual, pero podía ocultar relaciones de confianza importantes.

Los desarrolladores seguían teniendo que verificar que el contrato referenciado fuera la versión prevista y que sus permisos coincidieran con el diseño de seguridad de la aplicación.

Embark y los nombres de aplicaciones

Embark incluía integraciones históricas para sistemas de nombres descentralizados.

Un sistema de nombres puede asociar un nombre legible por personas a una cuenta, un contrato, un identificador de contenido u otro recurso blockchain.

Esto puede mejorar la usabilidad porque los usuarios no tienen que escribir direcciones hexadecimales largas.

Los nombres pueden caducar, transferirse, resolverse a un nuevo destino o quedar bajo el control de cuentas comprometidas.

Una aplicación no debe tratar un nombre legible como prueba permanente de la identidad de un contrato.

Las acciones de gran valor deben verificar la dirección resuelta y la red.

¿Qué ventajas ofrecía Embark Framework?

Embark ofrecía un flujo de trabajo unificado para contratos, código frontend, pruebas, despliegue, almacenamiento y comunicación.

Generaba automáticamente objetos de contrato JavaScript y artefactos de despliegue.

Supervisaba los archivos fuente y reconstruía o redesplegaba componentes cuando era necesario.

Admitía la gestión de dependencias entre varios contratos.

Ofrecía redes locales de desarrollo y pruebas con JavaScript.

Permitía configurar distintos entornos blockchain.

Proporcionaba un panel visual y una consola interactiva.

También ayudó a introducir la idea de que una aplicación descentralizada podía utilizar más elementos que una blockchain por sí sola.

¿Qué limitaciones tenía Embark Framework?

Embark intentaba coordinar numerosas tecnologías, lo que hacía que el framework fuera grande y complejo.

Su funcionamiento dependía de numerosos paquetes de Node.js, clientes blockchain, compiladores, herramientas de almacenamiento, bibliotecas frontend y plugins.

Un cambio incompatible en cualquier dependencia importante podía afectar a todo el entorno de desarrollo.

El despliegue automático y la generación de código podían dificultar que los principiantes entendieran los comandos y transacciones exactos que se ejecutaban.

El amplio conjunto de funciones también aumentaba el tiempo de instalación y la complejidad de resolución de problemas.

La falta de versiones estables recientes plantea ahora graves problemas de compatibilidad y de cadena de suministro de software.

Por qué los frameworks de desarrollo antiguos entrañan riesgos de seguridad

Un framework antiguo puede contener dependencias obsoletas con vulnerabilidades documentadas públicamente.

Su árbol de dependencias puede incluir paquetes que ya no se mantienen.

Los scripts de instalación pueden depender de registros, descargas de binarios o comandos del sistema obsoletos.

El framework puede no reconocer el comportamiento actual de los compiladores de Solidity ni las funciones modernas de la EVM.

Puede generar supuestos de gas poco seguros o utilizar parámetros de nodo discontinuados.

Las bibliotecas frontend antiguas pueden contener vulnerabilidades del navegador o comportamientos incompatibles de integración con wallets.

Que la instalación se complete correctamente no demuestra que el entorno de desarrollo resultante sea seguro.

Riesgos para la cadena de suministro de software

Instalar un framework de desarrollo JavaScript puede ejecutar código de numerosos paquetes directos e indirectos.

Un paquete comprometido puede leer variables de entorno, modificar archivos fuente, robar credenciales de firma o insertar código malicioso en las compilaciones generadas.

Los archivos de bloqueo heredados pueden resolver las dependencias de forma distinta si faltan versiones históricas de paquetes.

Los desarrolladores deben instalar proyectos antiguos en un entorno aislado y sin claves privadas valiosas.

Deben revisar el archivo de bloqueo, las sumas de comprobación de los paquetes, los scripts de instalación y el grafo de dependencias.

La firma de producción debe permanecer separada de un entorno de compilación heredado no fiable o reconstruido recientemente.

Seguridad de las claves privadas

Embark necesitaba acceso a una cuenta para desplegar contratos o enviar transacciones de desarrollo.

Guardar una clave privada sin cifrar o una frase de recuperación en la configuración del proyecto supone un grave riesgo de seguridad.

Una filtración del repositorio de código fuente podría exponer todos los activos controlados por esa clave.

Una dependencia maliciosa también podría leer archivos de configuración local o variables de entorno.

Los despliegues de producción deben utilizar un proceso de firma controlado, con fondos limitados y una revisión clara de las transacciones.

Una cuenta de desarrollo nunca debe reutilizarse como cuenta de tesorería o administración a largo plazo.

Verificación de contratos inteligentes

Desplegar un contrato mediante Embark no demostraba automáticamente que el código fuente público coincidiera con el bytecode desplegado.

La verificación de contratos permite comparar el código fuente publicado y la configuración del compilador con el código on-chain.

Los desarrolladores deben conservar la versión exacta del compilador, la configuración del optimizador, los argumentos del constructor, las bibliotecas y los archivos fuente utilizados en el despliegue.

Puede resultar difícil reproducir artefactos de proyectos heredados si desaparecen los binarios de compiladores antiguos o sus dependencias.

Por ello, las compilaciones reproducibles y los registros de despliegue archivados son importantes para mantener un proyecto de Embark.

Migración desde Embark

Migrar desde Embark no requiere necesariamente redesplegar todos los contratos inteligentes.

Un equipo puede conservar los contratos desplegados y sustituir los flujos de trabajo locales de compilación, pruebas, despliegue y compilación del frontend.

El primer paso es inventariar las direcciones de los contratos, los archivos fuente, las ABI, la configuración del compilador, los argumentos del constructor, las bibliotecas y las cuentas administrativas.

El siguiente paso es reproducir los contratos en un entorno de compilación moderno y aislado.

Cuando sea posible, las pruebas deben comparar los nuevos artefactos con el bytecode histórico desplegado.

A continuación, puede actualizarse el código frontend para cargar ABI y direcciones verificadas sin depender de los artefactos generados por Embark.

El redespliegue solo debe realizarse cuando sea necesario modificar los contratos y se comprendan los riesgos de migración.

Conservar un proyecto existente de Embark

Un equipo que mantenga una aplicación antigua de Embark debe archivar el repositorio completo de código fuente y el archivo de bloqueo.

Debe documentar la versión necesaria de Node.js, el sistema operativo, la versión del compilador, el cliente blockchain, las variables de entorno y el comportamiento del gestor de paquetes.

Las imágenes de contenedores o máquinas virtuales pueden ayudar a conservar un entorno histórico reproducible.

Esas imágenes deben analizarse y aislarse, ya que conservar un entorno también implica conservar sus vulnerabilidades.

Los contratos críticos deben documentarse al margen del framework para que los desarrolladores puedan interactuar con ellos aunque Embark deje de funcionar.

Las direcciones de despliegue y los roles de administrador deben verificarse directamente on-chain.

¿Deberían los desarrolladores iniciar un nuevo proyecto con Embark?

En general, los desarrolladores no deberían elegir Embark como base para una nueva aplicación cripto de producción en 2026.

El framework no recibe una versión estable desde abril de 2020.

Sus integraciones y dependencias documentadas se diseñaron para una versión anterior del entorno de desarrollo de Ethereum.

Un proyecto nuevo necesita herramientas con mantenimiento activo que admitan versiones actuales de compiladores, formatos de transacción, comportamiento de redes, métodos de prueba y prácticas de seguridad.

Embark aún puede ser útil para la investigación histórica, el mantenimiento de aplicaciones heredadas, el estudio de las primeras herramientas para DApps o la extracción de contratos y casos de prueba reutilizables.

Cualquier uso continuado debe realizarse en un entorno controlado y sin claves valiosas hasta que se haya revisado toda la cadena de dependencias.

Importancia histórica de Embark

Embark contribuyó a definir la idea de un framework full-stack para aplicaciones descentralizadas.

Consideraba los contratos inteligentes, el código frontend, el almacenamiento, la comunicación, las pruebas, el despliegue y las interfaces de desarrollo como partes de una misma aplicación.

Esto fue importante en una época en la que las herramientas de desarrollo blockchain estaban fragmentadas y eran difíciles de configurar.

Embark también puso al alcance de más desarrolladores JavaScript la generación automática de artefactos de contratos y el despliegue basado en dependencias.

Su integración de almacenamiento descentralizado animó a los desarrolladores a pensar más allá de usar el estado blockchain para todos los tipos de datos.

Muchos flujos de trabajo modernos siguen abordando los mismos problemas, aunque utilicen otras arquitecturas y herramientas.

Ejemplo de flujo de desarrollo con Embark

Supongamos que un desarrollador quiere crear una aplicación de votación sencilla basada en tokens.

Podría crear contratos de Solidity para el token y las reglas de votación.

La configuración de Embark podría describir el contrato del token y pasar su dirección desplegada al contrato de votación.

Embark podría iniciar una blockchain local, compilar ambos contratos, desplegarlos en el orden necesario y generar artefactos frontend.

La aplicación del navegador podría utilizar EmbarkJS para mostrar saldos de tokens y enviar transacciones de voto.

Las pruebas JavaScript podrían verificar que solo los titulares de tokens que cumplan los requisitos puedan votar y que una cuenta no pueda votar dos veces.

El frontend terminado podría compilarse y cargarse mediante la integración de almacenamiento descentralizado configurada.

Todos los componentes de este flujo seguirían necesitando una revisión de seguridad antes de un despliegue público.

Errores habituales con Embark Framework

Un error habitual es suponer que Embark sigue teniendo mantenimiento activo porque su repositorio continúa siendo público.

Otro es instalar directamente el antiguo paquete global en un equipo que contiene claves cripto valiosas.

Un tercero es considerar seguro el despliegue automático de contratos sin revisar los argumentos del constructor y las cuentas con privilegios.

Un cuarto es suponer que las pruebas locales reproducen todas las condiciones de una red pública.

Un quinto es guardar claves privadas de despliegue en archivos de configuración o en el control de versiones.

Un sexto es suponer que el almacenamiento descentralizado garantiza que los archivos estén disponibles permanentemente.

Un séptimo es confundir el envío correcto de una transacción con la ejecución correcta de un contrato inteligente.

Un octavo es utilizar artefactos generados para una red blockchain incorrecta.

Un noveno es migrar las herramientas de compilación sin verificar que el nuevo bytecode compilado coincida con los contratos históricos.

Un décimo es redesplegar un contrato de producción sin planificar cómo migrarán los usuarios, los activos, los permisos y el estado de la aplicación.

Preguntas frecuentes

¿Qué es Embark Framework?

Embark Framework es una herramienta heredada de código abierto para desarrollar, probar, desplegar y gestionar aplicaciones descentralizadas compatibles con Ethereum.

¿Qué lenguajes de programación utilizaba Embark?

Embark trabajaba principalmente con contratos inteligentes de Solidity y código de aplicación JavaScript o TypeScript.

¿Qué blockchains admitía Embark?

Se diseñó principalmente para Ethereum y otras redes compatibles con Ethereum Virtual Machine y con las interfaces JSON-RPC de estilo Ethereum.

¿Sigue activo Embark Framework?

El framework no recibe una versión estable desde la versión 6.0.0, publicada el 27 de abril de 2020, por lo que debe considerarse software heredado.

¿Cuál fue la última versión estable de Embark?

El repositorio oficial indica que la versión 6.0.0 es la última versión estable.

¿Hubo versiones posteriores a la 6.0.0?

El registro oficial de cambios recoge dos compilaciones nightly de la versión 6.0.1, en agosto y octubre de 2020, pero ninguna versión estable posterior.

¿Qué tareas automatizaba Embark?

Automatizaba la compilación de contratos, el despliegue basado en dependencias, la generación de artefactos, la reconstrucción del frontend, las pruebas, los servicios locales y algunas integraciones de almacenamiento o comunicación descentralizados.

¿Qué es EmbarkJS?

EmbarkJS es la capa de integración JavaScript que exponía al código de la aplicación los contratos inteligentes, el almacenamiento, la comunicación y otros servicios configurados.

¿Qué era Embark Cockpit?

Cockpit era el panel gráfico de desarrollo de Embark para visualizar contratos, transacciones, servicios, registros y actividad del proyecto.

¿Podía Embark ejecutar una blockchain local?

Sí. Podía iniciar o conectar con una red EVM local de desarrollo para desplegar y probar contratos.

¿Embark admitía pruebas de contratos inteligentes?

Sí. Admitía pruebas de contratos basadas en JavaScript y flujos de desarrollo basados en pruebas.

¿Embark admitía almacenamiento descentralizado?

Sí. Incluía integraciones históricas con IPFS y Swarm para almacenar archivos y desplegar aplicaciones.

¿Embark admitía mensajería descentralizada?

Sí. Las versiones históricas incluían integraciones con tecnologías de comunicación entre pares como Whisper y Orbit.

¿Podía Embark desplegar varios contratos conectados?

Sí. Podía registrar las dependencias entre contratos y desplegarlos en un orden que proporcionara las direcciones necesarias a los contratos dependientes.

¿Embark admitía frameworks frontend?

Sí. Su pipeline web se diseñó para funcionar con distintas tecnologías de navegador y procesos de compilación.

¿Embark era una blockchain?

No. Embark era software de desarrollo que se conectaba a blockchains y otras tecnologías descentralizadas.

¿Embark era una criptomoneda?

No. Era un framework de desarrollo de código abierto y no requería una criptomoneda nativa.

¿Embark hacía seguros los contratos inteligentes?

No. Admitía pruebas y desarrollo, pero no podía garantizar que el código, los permisos o la lógica económica de los contratos fueran seguros.

¿Pueden seguir funcionando on-chain los contratos de Embark?

Sí. Los contratos desplegados mediante Embark pueden seguir funcionando de forma independiente si su red y su bytecode siguen disponibles.

¿Un contrato existente de Embark necesita que se ejecute Embark?

No. Los contratos EVM desplegados son ejecutados por la blockchain y se puede acceder a ellos mediante cualquier interfaz compatible que utilice la dirección y la ABI correctas.

¿Puede un equipo migrar desde Embark sin mover sus contratos?

Sí. El equipo puede sustituir el flujo local de compilación y despliegue y seguir interactuando con los contratos existentes.

¿Es seguro instalar Embark hoy?

La instalación solo debe realizarse en un entorno aislado, tras revisar sus dependencias antiguas y sin exponer claves privadas valiosas.

¿Debería utilizar Embark un nuevo proyecto cripto?

En general, un nuevo proyecto de producción debería utilizar componentes de desarrollo con mantenimiento activo, en lugar de depender de la pila obsoleta de Embark.

¿Por qué es importante Embark desde el punto de vista histórico?

Fue uno de los primeros frameworks que combinaron contratos inteligentes, desarrollo frontend, despliegue automatizado, pruebas, almacenamiento, comunicación y herramientas visuales en un flujo de trabajo para DApps.

Conclusión

Embark Framework es un entorno de desarrollo de código abierto heredado, creado para simplificar el desarrollo full-stack de aplicaciones descentralizadas.

Automatizaba la compilación de Solidity, el despliegue de contratos, la gestión de dependencias, la generación de artefactos, la compilación del frontend, las pruebas y la interacción con blockchain.

También integraba tecnologías de almacenamiento y comunicación descentralizados mediante EmbarkJS y una arquitectura basada en plugins.

Funciones como el redespliegue automático, la gestión de una blockchain local, las pruebas JavaScript, la consola interactiva y el panel Cockpit hicieron que fuera influyente durante la primera expansión de las aplicaciones de Ethereum.

Su última versión estable fue la 6.0.0, publicada el 27 de abril de 2020, seguida de dos compilaciones nightly ese mismo año.

La falta de versiones recientes implica que sus dependencias, integraciones de nodos, módulos de almacenamiento, herramientas de compilación y supuestos sobre wallets pueden ser incompatibles con los sistemas actuales.

Los contratos existentes desplegados mediante Embark no necesitan el framework para seguir funcionando on-chain.

Los equipos que mantengan sistemas heredados pueden conservar las direcciones de los contratos y el estado blockchain mientras migran la compilación, las pruebas, el despliegue y el frontend a herramientas con mantenimiento activo.

Los desarrolladores que examinen Embark deben aislar el entorno, auditar las dependencias, proteger las claves privadas, verificar el bytecode de los contratos y probar todas las integraciones históricas.

Embark sigue siendo valioso como parte de la historia del desarrollo cripto, pero no debe confundirse con un framework de producción con mantenimiento actual.