20 publicaciones etiquetados con "Ethereum"

Explicación del Restaking: En el modelo de prueba de participación (proof-of-stake) de Ethereum, los validadores normalmente hacen staking de ETH para asegurar la red y ganar recompensas, con el riesgo de sufrir un slashing si se comportan mal. El Restaking permite que este mismo ETH en staking (o sus derivados de staking líquido) se reutilice para asegurar protocolos o servicios adicionales. EigenLayer introdujo el restaking a través de contratos inteligentes que permiten a los stakers de ETH participar para extender su seguridad a nuevos sistemas a cambio de un rendimiento extra. En la práctica, un validador de Ethereum puede registrarse en EigenLayer y otorgar a sus contratos permiso para imponer condiciones de slashing adicionales especificadas por protocolos externos. Si el validador actúa de forma maliciosa en cualquier servicio en el que haya optado por participar, los contratos de EigenLayer pueden aplicar un slashing a su ETH en staking, tal como lo haría Ethereum por violaciones del consenso. Este mecanismo transforma eficazmente la robusta seguridad del staking de Ethereum en una "Seguridad como Servicio" componible: los desarrolladores pueden tomar prestada la seguridad económica de Ethereum para impulsar nuevos proyectos, en lugar de empezar su propia red de validadores desde cero. Al aprovechar los más de 31 millones de ETH que ya aseguran Ethereum, el restaking de EigenLayer crea un mercado de "seguridad agrupada" donde múltiples servicios comparten la misma base de capital de confianza.

El Enfoque de EigenLayer: EigenLayer se implementa como un conjunto de contratos inteligentes de Ethereum que coordinan este proceso de restaking. Los validadores (o poseedores de ETH) que desean hacer restake depositan sus tokens de staking líquido o, en el caso de los stakers nativos, redirigen sus credenciales de retiro a un contrato gestionado por EigenLayer (a menudo llamado un EigenPod). Esto asegura que EigenLayer pueda aplicar el slashing bloqueando o quemando el ETH subyacente si es necesario. Los restakers siempre conservan la propiedad de su ETH (retirable después de un período de salida/depósito en garantía), pero participan en nuevas reglas de slashing además de las de Ethereum. A cambio, se vuelven elegibles para recompensas de restaking adicionales pagadas por los servicios que aseguran. El resultado final es una capa de seguridad modular: el conjunto de validadores y el stake de Ethereum se "alquilan" a protocolos externos. Como dice el fundador de EigenLayer, Sreeram Kannan, esto crea una "Nube Verificable" para la Web3, análogamente a cómo AWS ofrece servicios de computación, EigenLayer ofrece seguridad como servicio a los desarrolladores. La adopción temprana ha sido fuerte: a mediados de 2024, más de 4.9 millones de ETH (~$15 mil millones) se habían restakeado en EigenLayer, demostrando la demanda de los stakers por maximizar el rendimiento y de los nuevos protocolos por arrancar con una sobrecarga mínima. En resumen, el restaking en Ethereum reutiliza la confianza existente (ETH en staking) para asegurar nuevas aplicaciones, y EigenLayer proporciona la infraestructura para hacer este proceso componible y sin permisos.

Patrones de Diseño de los Servicios Validados Activamente (AVSs)​

¿Qué son los AVSs? Los Servicios Validados Activamente (AVSs) se refieren a cualquier servicio o red descentralizada que requiere su propio conjunto de validadores y reglas de consenso, pero que puede externalizar la seguridad a una plataforma de restaking como EigenLayer. En otras palabras, un AVS es un protocolo externo (fuera de la L1 de Ethereum) que contrata a los validadores de Ethereum para realizar algún trabajo de verificación. Los ejemplos incluyen sidechains o rollups, capas de disponibilidad de datos, redes de oráculos, puentes, secuenciadores compartidos, módulos de computación descentralizada y más. Cada AVS define una tarea de validación distribuida única; por ejemplo, un oráculo podría requerir la firma de fuentes de precios, mientras que una cadena de disponibilidad de datos (como EigenDA) requiere almacenar y certificar blobs de datos. Estos servicios ejecutan su propio software y posiblemente su propio consenso entre los operadores participantes, pero dependen de la seguridad compartida: el stake económico que los respalda es proporcionado por ETH en restaking (u otros activos) de los validadores de Ethereum, en lugar de un token nativo para cada nueva red.

Arquitectura y Roles: La arquitectura de EigenLayer separa claramente los roles en este modelo de seguridad compartida:

• Restakers – Stakers de ETH (o poseedores de LST) que optan por asegurar AVSs. Depositan en los contratos de EigenLayer, extendiendo su capital en staking como colateral para múltiples servicios. Los restakers pueden elegir qué AVSs apoyar, directamente o mediante delegación, y ganar recompensas de esos servicios. Crucialmente, asumen el riesgo de slashing si cualquier AVS apoyado reporta un comportamiento indebido.

• Operadores – Operadores de nodos que realmente ejecutan el software cliente fuera de la cadena para cada AVS. Son análogos a los mineros/validadores de la red del AVS. En EigenLayer, un operador debe registrarse y ser aprobado (inicialmente en una lista blanca) para unirse, y luego puede optar por servir a AVSs específicos. Los restakers delegan su stake a los operadores (si no ejecutan nodos ellos mismos), por lo que los operadores agregan el stake de potencialmente muchos restakers. Cada operador está sujeto a las condiciones de slashing de cualquier AVS que apoye, y gana comisiones o recompensas por su servicio. Esto crea un mercado de operadores que compiten en rendimiento y confiabilidad, ya que los AVSs preferirán operadores competentes y los restakers preferirán a aquellos que maximicen las recompensas sin incurrir en slashing.

• AVS (Servicio Validado Activamente) – El protocolo o servicio externo en sí, que típicamente consta de dos componentes: (1) un binario o cliente fuera de la cadena que los operadores ejecutan para realizar el servicio (p. ej., el software de un nodo de sidechain), y (2) un contrato AVS en la cadena desplegado en Ethereum que interactúa con EigenLayer. El contrato de Ethereum del AVS codifica las reglas para el slashing y la distribución de recompensas de ese servicio. Por ejemplo, podría definir que si se envían dos firmas conflictivas (prueba de equivocación por parte de un operador), se ejecuta un slashing de X ETH sobre el stake de ese operador. El contrato AVS se conecta a los gestores de slashing de EigenLayer para penalizar realmente el ETH en restaking cuando ocurren violaciones. Así, cada AVS puede tener lógica de validación y condiciones de fallo personalizadas, mientras depende de EigenLayer para hacer cumplir los castigos económicos utilizando el stake compartido. Este diseño permite a los desarrolladores de AVS innovar en nuevos modelos de confianza (incluso nuevos mecanismos de consenso o servicios criptográficos) sin reinventar un token de bonding/slashing para la seguridad.

• Consumidores/Usuarios de AVS – Finalmente, los usuarios finales u otros protocolos que consumen la salida del AVS. Por ejemplo, una dApp podría usar un AVS de oráculo para datos de precios o un rollup podría publicar datos en un AVS de disponibilidad de datos. Los consumidores pagan comisiones al AVS (a menudo financiando las recompensas que ganan los restakers/operadores) y dependen de su corrección, que está asegurada por la seguridad económica que el AVS ha arrendado de Ethereum.

Aprovechando la Seguridad Compartida: La belleza de este modelo es que incluso un servicio completamente nuevo puede comenzar su vida con garantías de seguridad del nivel de Ethereum. En lugar de reclutar e incentivar un nuevo conjunto de validadores, un AVS aprovecha un conjunto de validadores experimentado y económicamente comprometido desde el primer día. Cadenas o módulos más pequeños que serían inseguros por sí solos se vuelven seguros al apoyarse en Ethereum. Esta seguridad agrupada aumenta significativamente el costo de atacar cualquier AVS individual: un atacante necesitaría adquirir y hacer staking de grandes cantidades de ETH (u otro colateral en la lista blanca) y luego arriesgarse a perderlo a través del slashing. Debido a que muchos servicios comparten el mismo fondo de ETH en restaking, forman efectivamente un paraguas de seguridad compartida: el peso económico combinado del stake disuade los ataques a cualquiera de ellos. Desde la perspectiva de un desarrollador, esto modulariza la capa de consenso: te centras en la funcionalidad de tu servicio mientras EigenLayer se encarga de asegurarlo con un conjunto de validadores existente. Los AVSs pueden ser, por lo tanto, muy diversos. Algunos son servicios "horizontales" de propósito general que muchas dApps podrían usar (p. ej., un secuenciador descentralizado genérico o una red de computación fuera de la cadena), mientras que otros son "verticales" o específicos de la aplicación (adaptados a un nicho como un puente particular o un oráculo de DeFi). Los primeros ejemplos de AVSs en EigenLayer abarcan la disponibilidad de datos (p. ej., EigenDA), la secuenciación compartida para rollups (p. ej., Espresso, Radius), redes de oráculos (p. ej., eOracle), puentes entre cadenas (p. ej., Polymer, Hyperlane), computación fuera de la cadena (p. ej., Lagrange para pruebas ZK), y más. Todos estos aprovechan la misma base de confianza de Ethereum. En resumen, un AVS es esencialmente un módulo conectable que externaliza la confianza a Ethereum: define lo que los validadores deben hacer y qué constituye una falta sancionable con slashing, y EigenLayer hace cumplir esas reglas sobre un fondo de ETH que se utiliza globalmente para asegurar muchos de esos módulos.

Mecanismos de Incentivos para Restakers, Operadores y Desarrolladores​

Un diseño de incentivos robusto es fundamental para alinear a todas las partes en un ecosistema de restaking. EigenLayer y plataformas similares crean una situación "ganar-ganar-ganar" al ofrecer nuevos ingresos a los stakers y operadores mientras reducen los costos para los protocolos emergentes. Analicemos los incentivos por rol:

• Incentivos para los Restakers: Los restakers están motivados principalmente por el rendimiento. Al optar por EigenLayer, un staker de ETH puede ganar recompensas adicionales además de su rendimiento de staking estándar de Ethereum. Por ejemplo, un validador con 32 ETH en staking en la beacon chain de Ethereum continúa ganando el APR base de ~4-5%, pero si hace restake a través de EigenLayer, puede ganar simultáneamente comisiones o recompensas en tokens de múltiples AVSs que ayuda a asegurar. Esta "doble ganancia" aumenta drásticamente los retornos potenciales para los validadores. En el lanzamiento inicial de EigenLayer, los restakers recibieron puntos de incentivo que se convirtieron en airdrops del token EIGEN (para el arranque); más tarde se lanzó un mecanismo de recompensa continua (Incentivos Programáticos), distribuyendo millones de tokens EIGEN a los restakers como minería de liquidez. Más allá de los incentivos en tokens, los restakers se benefician de la diversificación de ingresos: en lugar de depender únicamente de las recompensas de bloque de Ethereum, pueden ganar en varios tokens de AVS o comisiones. Por supuesto, estas mayores recompensas conllevan un mayor riesgo (mayor exposición al slashing), por lo que los restakers racionales solo optarán por AVSs que consideren bien gestionados. Esto crea un control impulsado por el mercado: los AVSs deben ofrecer recompensas lo suficientemente atractivas para compensar el riesgo, o los restakers los evitarán. En la práctica, muchos restakers delegan en operadores profesionales, por lo que también pueden pagar una comisión al operador de sus recompensas. Aun así, los restakers pueden ganar significativamente al monetizar la capacidad de seguridad ociosa de su ETH en staking. (Notablemente, EigenLayer informa que más del 88% de todo el EIGEN distribuido se volvió a poner en staking/delegar de inmediato, lo que indica que los restakers están componiendo sus posiciones con entusiasmo).

• Incentivos para los Operadores: Los operadores en EigenLayer son los proveedores de servicios que hacen el trabajo pesado de ejecutar nodos para cada AVS. Su incentivo son los ingresos por comisiones o la participación en las recompensas pagadas por esos AVSs. Típicamente, un AVS pagará recompensas (en ETH, stablecoins o su propio token) a todos los validadores que lo aseguran; los operadores reciben esas recompensas en nombre del stake que alojan, y a menudo toman una parte (como una comisión) por proporcionar la infraestructura. EigenLayer permite a los restakers delegar en operadores, por lo que los operadores compiten para atraer la mayor cantidad posible de ETH en restaking: más stake delegado significa más tareas que pueden hacer y más comisiones ganadas. Esta dinámica alienta a los operadores a ser altamente confiables y a especializarse en AVSs que puedan ejecutar eficientemente (para evitar ser sancionados y maximizar el tiempo de actividad). Un operador con buena reputación puede asegurar una delegación mayor y, por lo tanto, mayores recompensas totales. Es importante destacar que los operadores enfrentan penalizaciones de slashing por mala conducta al igual que los restakers (ya que el stake que llevan puede ser sancionado), alineando su comportamiento con la ejecución honesta. El diseño de EigenLayer crea efectivamente un mercado abierto para servicios de validadores: los equipos de AVS pueden "contratar" operadores ofreciendo recompensas, y los operadores elegirán AVSs que sean rentables en relación con el riesgo. Por ejemplo, un operador podría centrarse en ejecutar un AVS de oráculo si tiene altas comisiones, mientras que otro podría ejecutar un AVS de capa de datos que requiere mucho ancho de banda pero paga bien. Con el tiempo, esperamos un equilibrio de libre mercado donde los operadores elijan la mejor combinación de AVSs y establezcan una división de comisiones apropiada con sus delegadores. Esto contrasta con el staking tradicional de una sola cadena donde los validadores tienen deberes fijos; aquí, pueden realizar múltiples tareas en varios servicios para acumular ganancias. El incentivo para los operadores es, por lo tanto, maximizar sus ganancias por unidad de colateral en staking, sin sobrecargarse hasta el punto de ser sancionados. Es un equilibrio delicado que debería impulsar la profesionalización e incluso soluciones de seguros o cobertura (los operadores podrían asegurarse contra el slashing para proteger a sus delegadores, etc.).

• Incentivos para los Desarrolladores de AVS: Los desarrolladores de protocolos (los equipos que construyen nuevos AVSs o cadenas) son posiblemente los que más tienen que ganar del modelo de "externalización de la seguridad" del restaking. Su principal incentivo es el ahorro de costes y tiempo: no necesitan lanzar un nuevo token con alta inflación ni persuadir a miles de validadores independientes para que aseguren su red desde cero. Arrancar una red PoS normalmente requiere dar a los primeros validadores grandes recompensas en tokens (diluyendo el suministro) y aún puede resultar en una seguridad débil si la capitalización de mercado del token es baja. Con la seguridad compartida, un nuevo AVS puede **entrar en funcionamiento asegurado por la seguridad económica de más de $200 mil millones de Ethereum**, haciendo que los ataques sean económicamente inviables al instante. Esto es un gran atractivo para proyectos de infraestructura como puentes u oráculos que necesitan fuertes garantías de seguridad. Además, los desarrolladores pueden centrarse en la lógica de su aplicación y confiar en EigenLayer (o Karak, etc.) para la **gestión del conjunto de validadores**, reduciendo enormemente la complejidad. Económicamente, aunque el AVS debe pagar por la seguridad, a menudo puede hacerlo de una manera **más sostenible**. En lugar de una inflación enorme, podría redirigir las comisiones del protocolo u ofrecer un modesto estipendio en su token nativo. Por ejemplo, un AVS de puente podría cobrar a los usuarios comisiones en ETH y usarlas para pagar a los restakers, logrando seguridad sin imprimir tokens sin respaldo. Un análisis reciente señala que eliminar la necesidad de "mecanismos de recompensa altamente dilutivos" fue una motivación clave detrás del diseño de restaking universal de Karak. Esencialmente, la seguridad compartida permite _"arrancar con un presupuesto limitado"_. Además, si el AVS tiene un token, puede usarse más para la gobernanza o la utilidad en lugar de puramente para el gasto en seguridad. Los desarrolladores también están incentivados por los **efectos de red**: al conectarse a un centro de restaking, su servicio puede interoperar más fácilmente con otros AVSs (usuarios y operadores compartidos) y ganar exposición a la gran comunidad de stakers de Ethereum. La otra cara de la moneda es que los equipos de AVS deben diseñar esquemas de recompensa convincentes para _atraer_ a restakers y operadores en el mercado abierto. Esto a menudo significa ofrecer inicialmente rendimientos generosos o incentivos en tokens para impulsar la participación, muy similar a la minería de liquidez en DeFi. Por ejemplo, el propio EigenLayer distribuyó el token EIGEN ampliamente a los primeros stakers/operadores para fomentar la participación. Vemos patrones similares con nuevas plataformas de restaking (p. ej., la campaña XP de Karak para futuros tokens$KAR). En resumen, los desarrolladores de AVS intercambian dar algunas recompensas a los stakers de Ethereum a cambio de evitar el problema del arranque en frío de asegurar una nueva red. La ganancia estratégica es un tiempo de comercialización más rápido y una mayor seguridad desde el primer día, lo que puede ser una ventaja decisiva, especialmente para infraestructuras críticas como puentes entre cadenas o servicios financieros que requieren confianza.

Riesgos Regulatorios y Preocupaciones de Gobernanza​

Incertidumbre Regulatoria: El novedoso modelo de restaking existe en una zona gris legal, planteando varias cuestiones regulatorias. Una preocupación es si ofrecer "seguridad como servicio" podría ser visto por los reguladores como una oferta de valores no registrada o una forma de producto de inversión de alto riesgo. Por ejemplo, la distribución del token EIGEN a través de un airdrop a stakers y las recompensas continuas han generado escrutinio sobre el cumplimiento de las leyes de valores. Los proyectos deben tener cuidado de que sus tokens o esquemas de recompensa no activen las definiciones de valores (p. ej., el test de Howey en los EE. UU.). Además, los protocolos de restaking agregan y reasignan stakes entre redes, lo que podría verse como una forma de inversión colectiva o incluso una actividad similar a la bancaria si no está debidamente descentralizada. El equipo de EigenLayer reconoce el riesgo regulatorio, señalando que las leyes cambiantes podrían afectar la viabilidad del restaking y que EigenLayer "podría ser clasificado como una actividad financiera ilegal en algunas regiones". Esto significa que los reguladores podrían determinar que ceder el control del slashing a servicios de terceros (AVSs) viola las reglas financieras o de protección al consumidor, especialmente si hay usuarios minoristas involucrados. Otro ángulo son las sanciones/AML (Anti-Lavado de Dinero): el restaking mueve el stake a contratos que luego validan otras cadenas; si una de esas cadenas procesa transacciones ilícitas o está sancionada, ¿podrían los validadores de Ethereum infringir involuntariamente las normativas de cumplimiento? Esto aún no se ha probado. Hasta ahora, no hay regulaciones claras que apunten específicamente al restaking, pero la postura evolutiva sobre el staking de criptomonedas (p. ej., las acciones de la SEC contra los servicios de staking centralizados) sugiere que el restaking podría atraer escrutinio a medida que crece. Proyectos como EigenLayer han adoptado un enfoque cauteloso; por ejemplo, el token EIGEN fue inicialmente no transferible en su lanzamiento para evitar el comercio especulativo y posibles problemas regulatorios. No obstante, hasta que se definan los marcos, las plataformas de restaking operan con el riesgo de que nuevas leyes o su aplicación puedan imponer restricciones (como requerir la acreditación de los participantes, divulgaciones o incluso prohibir ciertos tipos de staking entre cadenas).

Preocupaciones de Gobernanza y Consenso: El restaking introduce complejos desafíos de gobernanza tanto a nivel de protocolo como para el ecosistema más amplio de Ethereum:

• Sobrecargar el Consenso Social de Ethereum: Una preocupación prominente, expresada por Vitalik Buterin, es que los usos extendidos del conjunto de validadores de Ethereum podrían arrastrar inadvertidamente a Ethereum mismo a disputas externas. La advertencia de Vitalik: "El doble uso del ETH en staking de los validadores, aunque tiene algunos riesgos, es fundamentalmente aceptable, pero intentar 'reclutar' el consenso social de Ethereum para los propósitos de tu propia aplicación no lo es.". En términos sencillos, es aceptable si los validadores de Ethereum también validan, digamos, una red de oráculos y son sancionados individualmente por mal comportamiento allí (sin efecto en el consenso de Ethereum). Lo peligroso es si un protocolo externo espera que la comunidad o el protocolo central de Ethereum intervenga para resolver algún problema (por ejemplo, para bifurcar a los validadores que se comportaron mal en el servicio externo). El diseño de EigenLayer intenta conscientemente evitar este escenario manteniendo las faltas sancionables objetivas y aisladas. Las condiciones de slashing son criptográficas (p. ej., prueba de doble firma) y no requieren la intervención de la gobernanza de Ethereum, por lo que cualquier castigo está autocontenido en el contrato de EigenLayer y no implica que Ethereum altere su estado o reglas. En casos de faltas subjetivas (donde se necesita juicio humano, digamos para una disputa de precios de un oráculo), EigenLayer planea usar su propia gobernanza (p. ej., una votación del token EIGEN o un consejo) en lugar de cargar la capa social de Ethereum. Esta separación es crítica para mantener la neutralidad de Ethereum. Sin embargo, a medida que el restaking crece, existe un riesgo sistémico de que si ocurriera un incidente importante (como un error que cause un slashing masivo de una gran parte de los validadores), la comunidad de Ethereum podría verse presionada a responder (por ejemplo, revirtiendo los slashings). Eso enredaría a Ethereum en el destino de los AVSs externos, exactamente lo que Vitalik advierte. El riesgo del consenso social se refiere principalmente a casos extremos de "cisne negro", pero subraya la importancia de mantener el núcleo de Ethereum mínimo y no involucrado en la gobernanza del restaking.

• Cascadas de Slashing y Seguridad de Ethereum: Relacionado con lo anterior, existe la preocupación de que los eventos de slashing en el restaking podrían generar una cascada y comprometer a Ethereum. Si un AVS muy popular (con muchos validadores) sufriera un fallo catastrófico que llevara a un slashing masivo, miles de validadores de ETH podrían perder su stake o ser forzados a salir. En el peor de los casos, si se sanciona suficiente stake, el propio conjunto de validadores de Ethereum podría reducirse o centralizarse rápidamente. Por ejemplo, imagina que un operador de EigenLayer de primer nivel que ejecuta el 10% de todos los validadores es sancionado en un AVS; esos validadores podrían desconectarse después de perder fondos, reduciendo la seguridad de Ethereum. Chorus One (un servicio de staking) analizó EigenLayer y señaló que este riesgo de cascada se exacerba si el mercado de restaking lleva a que solo unos pocos grandes operadores dominen. La buena noticia es que, históricamente, el slashing en Ethereum es raro y generalmente a pequeña escala. EigenLayer también limitó inicialmente la cantidad de stake y deshabilitó el slashing mientras el sistema era nuevo. Para abril de 2025, EigenLayer habilitó el slashing en la mainnet con un monitoreo cuidadoso. Para mitigar aún más los slashings no intencionados (p. ej., debido a errores), EigenLayer introdujo "comités de veto de slashing", esencialmente una multifirma (multisig) de expertos que pueden anular un slashing si parece ser un error o un ataque al protocolo. Esta es una medida centralizadora temporal, pero aborda el riesgo de que un contrato inteligente de AVS defectuoso cause estragos. Con el tiempo, dichos comités podrían ser reemplazados por una gobernanza más descentralizada o salvaguardas.

• Centralización del Restaking y la Gobernanza: Una preocupación clave de gobernanza es quién controla el protocolo de restaking y sus parámetros. En las primeras etapas de EigenLayer, las actualizaciones y decisiones críticas estaban controladas por una multifirma del equipo y la comunidad cercana (p. ej., una multifirma de 9 de 13). Esto es práctico para la seguridad en el desarrollo rápido, pero es un riesgo de centralización: esos poseedores de claves podrían coludir o ser comprometidos para cambiar maliciosamente las reglas (por ejemplo, para robar los fondos en staking). Reconociendo esto, EigenLayer estableció un marco más formal de EigenGov a finales de 2024, introduciendo un Consejo del Protocolo de expertos y un proceso de gobernanza comunitaria para los cambios. El consejo ahora controla las actualizaciones a través de una multifirma de 3 de 5, con supervisión comunitaria. Con el tiempo, la intención es evolucionar hacia una gobernanza de los poseedores de tokens o un modelo completamente descentralizado. Aun así, en cualquier sistema de restaking, las decisiones de gobernanza (como qué nuevo colateral admitir, qué AVS "bendecir" con estatus oficial, cómo se resuelven las disputas de slashing) tienen mucho en juego. Existe un conflicto de intereses potencial: los grandes proveedores de staking (como Lido o los exchanges) podrían influir en la gobernanza para favorecer a sus operadores o activos. De hecho, está surgiendo la competencia (p. ej., los fundadores de Lido respaldando Symbiotic, una plataforma de restaking de múltiples activos) y uno puede imaginar guerras de gobernanza si, por ejemplo, surge una propuesta para prohibir un cierto AVS que se considera arriesgado. La propia capa de restaking necesita una gobernanza robusta para gestionar tales problemas de manera transparente.

• Centralización de Validadores: En el lado operativo, existe la preocupación de que los AVSs elegirán preferentemente a los grandes operadores, causando centralización en quién valida realmente la mayoría de los servicios en restaking. Si, por eficiencia, muchos equipos de AVS seleccionan a un puñado de validadores profesionales (p. ej., grandes empresas de staking) para que les presten servicio, esas entidades ganan un poder y una cuota de recompensas desproporcionados. Podrían entonces socavar a otros ofreciendo mejores condiciones (gracias a las economías de escala), convirtiéndose potencialmente en un oligopolio. Esto refleja las preocupaciones en el staking de Ethereum tradicional (p. ej., el dominio de Lido). El restaking podría amplificarlo, ya que los operadores que ejecutan múltiples AVSs tienen más fuentes de ingresos. Esto es tanto una preocupación económica como de gobernanza: podría requerir límites impuestos por la comunidad o incentivos para fomentar la descentralización (por ejemplo, EigenLayer podría limitar cuánto stake puede controlar un operador, o se podría requerir a los AVSs que distribuyan sus asignaciones). Sin controles, la dinámica de "los ricos se hacen más ricos" podría llevar a que unos pocos operadores de nodos controlen efectivamente grandes franjas del conjunto de validadores de Ethereum en muchos servicios, lo cual es perjudicial para la descentralización. La comunidad está discutiendo activamente tales problemas, y algunos han propuesto que los protocolos de restaking incluyan mecanismos para favorecer a los operadores más pequeños o hacer cumplir la diversidad (quizás a través de la estrategia de delegación o mediante la coordinación social de las comunidades de stakers).

En resumen, aunque el restaking desbloquea una tremenda innovación, también introduce nuevos vectores de riesgo. Los reguladores están observando si esto representa productos de rendimiento no regulados o si plantea peligros sistémicos. El liderazgo de Ethereum subraya la importancia de no enredar la gobernanza de la capa base en estos nuevos usos. La comunidad de EigenLayer y otros han respondido con un diseño cuidadoso (solo slashing objetivo, tokens de dos niveles para diferentes tipos de fallos, investigación de AVSs, etc.) y un control central interino para prevenir accidentes. Los desafíos de gobernanza en curso incluyen descentralizar el control sin sacrificar la seguridad, asegurar la participación abierta en lugar de la concentración, y establecer marcos legales claros. A medida que estas redes de restaking maduren, es de esperar que surjan estructuras de gobernanza mejoradas y posiblemente estándares o regulaciones de la industria que aborden estas preocupaciones.

EigenLayer vs. Karak vs. Babylon: Un Análisis Comparativo​

El panorama del restaking/seguridad compartida ahora incluye varios marcos con diferentes diseños. Aquí comparamos EigenLayer, Karak Network y Babylon, destacando sus arquitecturas técnicas, modelos económicos y enfoque estratégico:

Arquitectura Técnica y Base de Seguridad: EigenLayer es un protocolo nativo de Ethereum (contratos inteligentes en la L1 de Ethereum) que aprovecha el ETH en staking (y los Tokens de Staking Líquido equivalentes) como colateral de seguridad. Se "apoya" en la beacon chain de Ethereum: los validadores optan por participar a través de contratos de Ethereum, y el slashing se aplica sobre su stake de ETH. Esto significa que la seguridad de EigenLayer está fundamentalmente ligada al PoS de Ethereum y al valor de ETH. En contraste, Karak se posiciona como una "capa de restaking universal" no ligada a una única cadena base. Karak lanzó su propia blockchain L1 (con compatibilidad EVM) optimizada para servicios de seguridad compartida. El modelo de Karak es agnóstico a la cadena y a los activos: permite el restaking de muchos tipos de activos a través de múltiples cadenas, no solo ETH. El colateral admitido incluye ETH y LSTs además de otros ERC-20 (stablecoins como USDC/sDAI, tokens LP, e incluso otros tokens de L1). Esto significa que la base de seguridad de Karak es una cesta diversificada; la validación en Karak podría estar respaldada por, digamos, una combinación de ETH en staking, SOL en staking (si se puentea), stablecoins, etc., dependiendo de lo que acepte el AVS (o "VaaS" en la terminología de Karak). Babylon toma una ruta diferente: aprovecha la seguridad de Bitcoin (BTC), el mayor criptoactivo, para asegurar otras cadenas. Babylon está construido como una cadena basada en Cosmos (Babylon Chain) que se conecta a Bitcoin y a cadenas PoS a través del protocolo IBC. Los poseedores de BTC bloquean BTC nativo en la mainnet de Bitcoin (en una ingeniosa bóveda con bloqueo de tiempo) y, por lo tanto, "hacen staking" de BTC en Babylon, que luego lo utiliza como colateral para asegurar las cadenas PoS consumidoras. Así, la base de seguridad de Babylon es el valor de Bitcoin (más de $500 mil millones de capitalización de mercado), aprovechado de una manera sin confianza (sin BTC envuelto ni custodios; utiliza scripts de Bitcoin para aplicar el slashing). En resumen, EigenLayer depende de la seguridad económica de Ethereum, Karak es multi-activo y multi-cadena (una capa genérica para cualquier colateral), y Babylon extiende la seguridad de prueba de trabajo (proof-of-work) de Bitcoin a los ecosistemas PoS.

Mecanismo de Restaking: En EigenLayer, el restaking es opcional a través de contratos de Ethereum; el slashing es programático y se hace cumplir por el consenso de Ethereum (respetando los contratos de EigenLayer). Karak, como una L1 independiente, mantiene su propia lógica de restaking en su cadena. Karak introdujo el concepto de Validación como Servicio (VaaS), análogo al AVS de Eigen, pero con un mercado de validadores universal a través de las cadenas. Los validadores de Karak (operadores) ejecutan su cadena y cualquier número de Servicios Seguros Distribuidos (DSS), que son el equivalente de Karak a los AVSs. Un DSS podría ser una nueva blockchain específica de una aplicación o un servicio que alquila seguridad del fondo de activos en staking de Karak. La innovación de Karak es estandarizar los requisitos para que cualquier cadena o aplicación (Ethereum, Solana, una L2, etc.) pueda conectarse y usar su red de validadores y su variado colateral. El slashing en Karak sería manejado por las reglas de su protocolo; dado que puede hacer staking de, por ejemplo, USDC, presumiblemente sanciona el USDC de un validador si se comporta mal en un servicio (la mecánica exacta de slashing multi-activo es compleja y no pública, pero la idea es similar: cada colateral puede ser retirado si se prueban las violaciones). El mecanismo de Babylon es único debido a las limitaciones de Bitcoin: Bitcoin no admite contratos inteligentes para el auto-slashing, por lo que Babylon utiliza trucos criptográficos. El BTC se bloquea en una salida especial que requiere una clave. Si un participante que hace staking de BTC hace trampa (p. ej., firma dos bloques conflictivos en una cadena cliente), el protocolo aprovecha un esquema de firma de un solo uso extraíble (EOTS) para revelar la clave privada del participante, permitiendo que su BTC bloqueado sea transferido a una dirección de quema. En términos más simples, el mal comportamiento hace que el staker de BTC se sancione a sí mismo, ya que el acto de hacer trampa entrega el control de su depósito (que luego se destruye). La cadena basada en Cosmos de Babylon coordina este proceso y se comunica con las cadenas asociadas (a través de IBC) para proporcionar servicios como puntos de control y finalidad utilizando las marcas de tiempo de BTC. En Babylon, los validadores de la cadena Babylon (llamados proveedores de finalidad) son separados: ejecutan el consenso de Babylon y ayudan a retransmitir información a Bitcoin, pero no proporcionan seguridad económica; la seguridad económica proviene puramente del BTC bloqueado.

Modelo Económico y Recompensas: El modelo económico de EigenLayer se centra en la economía de staking de Ethereum. Los restakers ganan recompensas específicas de cada AVS, que podrían pagarse en comisiones de ETH, el token propio del AVS u otros tokens, dependiendo del diseño de cada AVS. El propio EigenLayer introdujo el token $EIGEN en gran medida para la gobernanza y para recompensar a los primeros participantes, pero no se requiere que los AVSs usen o paguen en EIGEN (no es un token de gas para ellos). La plataforma apunta a un equilibrio de libre mercado donde cada AVS establece una tasa de recompensa para atraer suficiente seguridad. **Karak** parece estar lanzando su token nativo$KAR (aún no disponible a principios de 2025) como el activo principal en su ecosistema. Karak recaudó $48 millones y fue respaldado por importantes inversores, lo que implica que$KAR tendrá valor y probablemente se usará para la gobernanza y posiblemente para el pago de comisiones en la red de Karak. Sin embargo, la principal promesa de Karak es "sin inflación" para las nuevas redes que lo aprovechan: en lugar de emitir sus propios tokens para la seguridad, aprovechan los activos existentes a través de Karak. Así, una nueva cadena que use Karak podría pagar a los validadores, por ejemplo, con sus comisiones de transacción (que podrían ser en una stablecoin o en el token nativo de la cadena si tiene uno), pero no necesitaría acuñar continuamente nuevos tokens para las recompensas de staking. Karak estableció un mercado de validadores donde los desarrolladores pueden publicar recompensas para que los validadores hagan restake de activos y aseguren su servicio. Este enfoque de mercado tiene como objetivo hacer que las recompensas sean más competitivas y consistentes en lugar de una inflación extremadamente alta seguida de un colapso, teóricamente reduciendo los costos para los desarrolladores y dando a los validadores ingresos multi-cadena estables. La economía de Babylon también difiere: los stakers de BTC que bloquean su Bitcoin ganan rendimiento en los tokens de las redes que están asegurando. Por ejemplo, si haces staking de BTC para ayudar a asegurar una zona de Cosmos (una de las cadenas cliente de Babylon), recibes las recompensas de staking de esa zona (su token de staking nativo) como si fueras un delegador allí. Esas cadenas asociadas se benefician al obtener una capa extra de seguridad (puntos de control en Bitcoin, etc.), y a cambio asignan una porción de su inflación o comisiones a los stakers de BTC a través de Babylon. En efecto, Babylon actúa como un centro donde los poseedores de BTC pueden delegar seguridad a muchas cadenas y ser pagados en muchos tokens. La propia cadena de Babylon tiene un token llamado $BABY**, utilizado para hacer staking en el propio consenso de Babylon (Babylon todavía necesita sus propios validadores PoS para ejecutar la infraestructura de la cadena).$BABY también se utiliza probablemente en la gobernanza y quizás para alinear incentivos (por ejemplo, los proveedores de finalidad hacen staking de BABY). Pero es importante destacar que $BABY **no** reemplaza a BTC como fuente de seguridad, es más para ejecutar la cadena, mientras que BTC es el colateral que respalda el servicio de seguridad compartida. A mayo de 2025, Babylon se había arrancado con éxito con más de **50,000 BTC en staking (~$5.5 mil millones) por parte de los poseedores de BTC, convirtiéndola en una de las cadenas de Cosmos más seguras por capital. Esos stakers de BTC luego ganan recompensas de staking de múltiples cadenas conectadas (p. ej., ATOM de Cosmos Hub, OSMO de Osmosis, etc.), logrando un rendimiento diversificado mientras mantienen BTC.

Enfoque Estratégico y Casos de Uso: La estrategia de EigenLayer ha estado centrada en Ethereum, con el objetivo de acelerar la innovación dentro del ecosistema de Ethereum. Sus primeros casos de uso objetivo (disponibilidad de datos, middleware como oráculos, secuenciación de rollups) mejoran Ethereum o sus rollups. Esencialmente, sobrecarga a Ethereum como una meta-capa de servicios, y ahora con su planeado soporte "multi-cadena" (añadido en 2025), EigenLayer permitirá que los AVSs se ejecuten en otras cadenas EVM o L2s mientras siguen usando el conjunto de validadores de Ethereum. Esta verificación entre cadenas significa que EigenLayer está evolucionando hacia un proveedor de seguridad entre cadenas, pero anclado en Ethereum (los validadores y el staking todavía viven en Ethereum para el slashing). Karak se posiciona como una capa base extensible globalmente para todo tipo de aplicaciones, no solo infraestructura cripto, sino también activos del mundo real, mercados financieros, e incluso servicios gubernamentales, según su marketing. El nombre "Capa Base Global para el PIB Programable" insinúa una ambición de trabajar con instituciones y estados-nación. Karak enfatiza la integración de las finanzas tradicionales y la IA, sugiriendo que buscará asociaciones más allá del ámbito cripto-nativo. Técnicamente, al admitir activos como stablecoins y potencialmente monedas gubernamentales, Karak podría permitir, por ejemplo, que un gobierno lance una blockchain asegurada por su propio token fiduciario en staking a través de los validadores de Karak. Su soporte para empresas y múltiples jurisdicciones es un diferenciador. En esencia, Karak está tratando de ser "restaking para todos, en cualquier cadena, con cualquier activo", una red más amplia que el enfoque de EigenLayer centrado en Ethereum. El enfoque de Babylon es tender un puente entre los ecosistemas de Bitcoin y Cosmos (y PoS en general). Mejora específicamente la seguridad entre cadenas al proporcionar la inmutabilidad y el peso económico de Bitcoin a cadenas de prueba de participación que de otro modo serían más pequeñas. Una de las aplicaciones estrella de Babylon es agregar puntos de control de finalidad de Bitcoin a las cadenas PoS, lo que hace extremadamente difícil que esas cadenas sean atacadas o reorganizadas sin atacar también a Bitcoin. Babylon, por lo tanto, se promociona como el que trae "la seguridad de Bitcoin a todo el mundo cripto". Su enfoque a corto plazo ha sido en las cadenas del SDK de Cosmos (a las que llama Redes Supercargadas por Bitcoin en la Fase 3), pero el diseño está pensado para ser interoperable con Ethereum y los rollups también. Estratégicamente, Babylon aprovecha la vasta base de poseedores de BTC, dándoles una opción de rendimiento (BTC es de otro modo un activo que no genera rendimiento) y al mismo tiempo ofreciendo a las cadenas acceso al "estándar de oro" de la seguridad cripto (BTC + PoW). Esto es bastante distinto de EigenLayer y Karak, que se centran más en aprovechar los activos PoS.

Tabla: EigenLayer vs Karak vs Babylon

Diferencias Estratégicas: EigenLayer se beneficia del masivo conjunto de validadores descentralizados y la credibilidad de Ethereum, pero está limitado a la seguridad basada en ETH. Sobresale al servir a proyectos orientados a Ethereum (muchos AVSs son proyectos de rollup o middleware de Ethereum). La estrategia de Karak es capturar un mercado más grande siendo flexible en el soporte de activos y cadenas: no está casado con Ethereum e incluso argumenta que los desarrolladores pueden evitar estar "confinados exclusivamente a Ethereum para la seguridad". Esto podría atraer a proyectos en ecosistemas como Arbitrum, Polygon, o incluso cadenas no EVM que desean un proveedor de seguridad neutral. El enfoque multi-activo de Karak también significa que puede aprovechar activos que tienen rendimientos más bajos en otros lugares; como señaló el cofundador Raouf Ben-Har, "Muchos activos tienen costos de oportunidad más bajos en comparación con ETH... lo que significa que [nuestros servicios] tienen un camino más fácil hacia rendimientos sostenibles.". Por ejemplo, el ARB (token de Arbitrum) en staking actualmente tiene pocos usos; Karak podría permitir a los poseedores de ARB hacer restake para asegurar nuevas dApps, creando una situación de ganar-ganar (rendimiento para los poseedores de ARB, seguridad para la dApp). Esta estrategia, sin embargo, conlleva complejidad técnica (gestionar diferentes riesgos de activos) y suposiciones de confianza (puentear activos a la plataforma de Karak de forma segura). La estrategia de Babylon es distinta al centrarse en Bitcoin: está aprovechando el mayor criptoactivo por capitalización de mercado, que también tiene una comunidad y un perfil de uso muy diferentes (poseedores a largo plazo). Babylon básicamente desbloqueó una nueva fuente de staking que antes no se había aprovechado: $1.2 billones de BTC que no podían hacer staking de forma nativa. Al hacerlo, aborda un enorme fondo de seguridad y se dirige a cadenas que valoran las garantías de Bitcoin. También atrae a los poseedores de Bitcoin dándoles una forma de ganar rendimiento sin renunciar a la custodia de BTC. Se podría decir que Babylon es casi lo contrario de EigenLayer: en lugar de extender la seguridad de Ethereum hacia afuera, está importando la seguridad de Bitcoin a las redes PoS. Estratégicamente, podría unificar los mundos históricamente separados de Bitcoin y DeFi.

Cada uno de estos marcos tiene sus ventajas y desventajas. EigenLayer actualmente disfruta de una ventaja del primer jugador en el restaking de Ethereum y un gran TVL (~$20 mil millones en restaking a finales de 2024), además de un profundo apoyo de la comunidad de Ethereum. Karak es más nuevo (la mainnet se lanzó en abril de 2024) y tiene como objetivo crecer cubriendo nichos que EigenLayer no cubre (colateral no ETH, cadenas no Ethereum). Babylon opera en el ámbito de Cosmos y aprovecha Bitcoin; no compite con EigenLayer por los stakers de ETH, sino que ofrece un servicio ortogonal (algunos proyectos podrían usar ambos). Estamos viendo una convergencia donde múltiples capas de restaking podrían incluso interoperar: p. ej., una L2 de Ethereum podría usar EigenLayer para la seguridad basada en ETH y también aceptar la seguridad de BTC a través de Babylon, demostrando que estos modelos no son mutuamente excluyentes, sino parte de un "mercado de seguridad compartida" más amplio.

Desarrollos Recientes y Actualizaciones del Ecosistema (2024–2025)​

Progreso de EigenLayer: Desde su inicio en 2021, EigenLayer ha evolucionado rápidamente de un concepto a una red en vivo. Se lanzó en la mainnet de Ethereum por etapas: la Etapa 1 a mediados de 2023 habilitó el restaking básico, y para abril de 2024 se desplegó el protocolo completo de EigenLayer (con soporte para operadores y AVSs iniciales). El crecimiento del ecosistema ha sido sustancial: a principios de 2025, EigenLayer informa de 29 AVSs en vivo en la mainnet (y más de 130 en desarrollo) que van desde capas de datos hasta oráculos. Más de 200 operadores y decenas de miles de restakers están participando, contribuyendo a un TVL en restaking que alcanzó los ~$20 mil millones a finales de 2024. Un hito importante fue la introducción de la aplicación de slashing y recompensas en la mainnet en abril de 2025, marcando el paso final para que el modelo de seguridad de EigenLayer entre en vigor. Esto significa que los AVSs ahora pueden penalizar verdaderamente el mal comportamiento y pagar recompensas sin confianza, superando la "fase de prueba" donde estas funciones estaban desactivadas. Junto con esto, EigenLayer implementó una serie de actualizaciones: por ejemplo, la actualización MOOCOW (julio de 2025) mejoró la eficiencia de los validadores al permitir retiros y consolidación de restake más fáciles (aprovechando la bifurcación Pectra de Ethereum). Quizás la nueva característica más significativa es la Verificación Multi-Cadena, lanzada en julio de 2025, que permite a los AVSs operar en múltiples cadenas (incluidas las L2s) mientras siguen utilizando la seguridad basada en Ethereum. Esto se demostró en la testnet de Base Sepolia y se implementará en la mainnet, convirtiendo efectivamente a EigenLayer en un proveedor de seguridad entre cadenas (no solo para aplicaciones de la L1 de Ethereum). Aborda una limitación anterior de que los AVSs de EigenLayer tenían que publicar todos los datos en Ethereum; ahora un AVS puede ejecutarse en, digamos, un Optimistic Rollup u otra L1, y EigenLayer verificará las pruebas (usando raíces de Merkle) de vuelta en Ethereum para sancionar o recompensar según sea necesario. Esto expande enormemente el alcance y el rendimiento de EigenLayer (los AVSs pueden ejecutarse donde es más barato manteniendo la seguridad de Ethereum). En términos de comunidad y gobernanza, EigenLayer implementó EigenGov a finales de 2024, un consejo y un marco de ELIP (Propuesta de Mejora de EigenLayer) para descentralizar la toma de decisiones. El Consejo del Protocolo (5 miembros) ahora supervisa los cambios críticos con la participación de la comunidad. Además, EigenLayer ha sido consciente de las preocupaciones planteadas por la comunidad central de Ethereum. En respuesta a las advertencias de Vitalik, el equipo ha publicado materiales explicando cómo evitan sobrecargar el consenso de Ethereum, por ejemplo, utilizando el token EIGEN para cualquier servicio "subjetivo" y dejando el restaking de ETH para casos de slashing puramente objetivos. Este enfoque de dos niveles (ETH para fallos claros, EIGEN para decisiones más subjetivas o lideradas por la gobernanza) todavía se está perfeccionando, pero muestra el compromiso de EigenLayer de alinearse con el ethos de Ethereum.

En el lado del ecosistema, la aparición de EigenLayer ha inspirado una ola de innovación y discusión. A mediados de 2024, los analistas señalaron que el restaking se había convertido en "una narrativa líder dentro de la comunidad de Ethereum". Muchos proyectos de DeFi e infraestructura comenzaron a planificar cómo aprovechar EigenLayer para la seguridad o un rendimiento adicional. Al mismo tiempo, los miembros de la comunidad están debatiendo la gestión de riesgos: por ejemplo, el detallado informe de riesgos de Chorus One (abril de 2024) llamó la atención sobre la centralización de operadores y los riesgos de slashing en cascada, lo que provocó más investigación y posiblemente características como el monitoreo de la distribución del stake. La distribución del token EIGEN también fue un tema candente: en el cuarto trimestre de 2024, EigenLayer realizó un "stake drop" donde los usuarios activos de Ethereum y los primeros participantes de EigenLayer recibieron EIGEN, pero inicialmente no era transferible. Algunos miembros de la comunidad no estaban contentos con aspectos del drop (p. ej., grandes porciones asignadas a VCs, y algunos protocolos de DeFi que integraron EigenLayer no fueron recompensados directamente). Esta retroalimentación ha llevado al equipo a enfatizar incentivos más centrados en la comunidad en el futuro, y de hecho los Incentivos Programáticos introducidos tienen como objetivo recompensar continuamente a aquellos que realmente hacen restaking y operan. Para 2025, EigenLayer es uno de los ecosistemas de desarrolladores de más rápido crecimiento, incluso reconocido en un informe de Electric Capital, y ha asegurado importantes asociaciones (p. ej., con LayerZero, ConsenSys, Risc0) para impulsar la adopción de AVSs. En general, la trayectoria de EigenLayer en 2024–2025 muestra una plataforma en maduración que aborda las preocupaciones iniciales y expande su funcionalidad, consolidando su posición como el pionero del restaking en Ethereum.

Karak y Otros Competidores: Karak Network saltó a la fama con su lanzamiento de mainnet en abril de 2024 y rápidamente se posicionó como un notable rival de EigenLayer en Ethereum y más allá. Respaldado por grandes inversores e incluso ciertos interesados de Ethereum (Coinbase Ventures, entre otros), la promesa de Karak de "restaking para todos, en cualquier cadena, con cualquier activo" atrajo la atención. A finales de 2024, Karak se actualizó a una mainnet V2 con características mejoradas para la seguridad universal, completando las migraciones a través de Arbitrum y Ethereum para noviembre de 2024. Esto indica que Karak expandió el soporte para más activos y posiblemente mejoró sus contratos inteligentes o consenso. A principios de 2025, Karak había aumentado su base de usuarios a través de un programa de incentivos XP (fomentando la participación en la testnet, el staking, etc., con la esperanza de un futuro airdrop de $KAR). Las discusiones comunitarias sobre Karak a menudo lo comparan con EigenLayer: Bankless señaló en mayo de 2024 que, si bien el valor total en staking de Karak todavía estaba "lejos del tamaño de EigenLayer", había experimentado un rápido crecimiento (4x en un mes) posiblemente debido a que los usuarios buscaban mayores recompensas o se diversificaban lejos de EigenLayer. El atractivo de Karak radica en admitir activos como tokens de rendimiento de Pendle, ARB de Arbitrum, el token de Mantle, etc., lo que amplía el mercado de restaking. A partir de 2025, es probable que Karak se esté centrando en incorporar más clientes de "Validación como Servicio" y posiblemente preparando el lanzamiento de su token KAR (su documentación sugiere seguir los canales oficiales para actualizaciones del token). La competencia entre EigenLayer y Karak sigue siendo amistosa pero significativa: ambos tienen como objetivo atraer a stakers y proyectos. Si EigenLayer mantiene el segmento maximalista de ETH, Karak es atractivo para los usuarios multi-cadena y aquellos con activos no ETH que buscan rendimiento. Podemos esperar que Karak anuncie asociaciones en el próximo año, quizás con redes de Capa 2 o incluso con actores institucionales dada su marca de "grado institucional". El mercado de restaking no es, por lo tanto, un monopolio; más bien, múltiples plataformas están encontrando nichos, lo que podría llevar a un ecosistema fragmentado pero rico de proveedores de seguridad compartida.

Lanzamiento de Babylon y la Frontera del Staking de BTC: Babylon completó un hito importante en 2025 al activar su funcionalidad principal: el staking de Bitcoin para seguridad compartida. Después de una testnet de Fase 1 y un despliegue gradual, la mainnet de la Fase 2 de Babylon se activó en abril de 2025, y para mayo de 2025 informó de más de 50k BTC en staking en el protocolo. Este es un logro notable, efectivamente _conectando ~$5 mil millones de Bitcoin_ al mercado de seguridad entre cadenas. Las primeras cadenas adoptantes de Babylon (las primeras "Redes Supercargadas por Bitcoin") incluyen varias cadenas basadas en Cosmos que integraron el cliente ligero de Babylon y comenzaron a depender de la finalidad de los puntos de control de BTC. La propia **cadena Génesis de Babylon** se lanzó el 10 de abril de 2025, asegurada por el nuevo staking del token$BABY, y un día después (11 de abril) se pilotó el staking de BTC sin confianza con un límite inicial de 1000 BTC. Para el 24 de abril de 2025, el staking de BTC se abrió sin permisos para todos, y se levantó el límite. El funcionamiento sin problemas durante las primeras semanas llevó al equipo a declarar que el staking de Bitcoin se había "arrancado con éxito", llamando a Babylon Genesis ahora "una de las L1 más seguras del mundo en términos de capitalización de mercado de staking". Con la Fase 2 completa, la Fase 3 tiene como objetivo incorporar muchas redes externas como clientes, convirtiéndolas en BSNs (Redes Supercargadas por Bitcoin). Esto implicará módulos de interoperabilidad para que Ethereum, sus rollups y cualquier cadena de Cosmos puedan usar Babylon para obtener seguridad de BTC. La comunidad de Babylon, que comprende poseedores de Bitcoin, desarrolladores de Cosmos y otros, ha estado discutiendo activamente la gobernanza del token $BABY (asegurando que la cadena de Babylon permanezca neutral y confiable para todas las cadenas conectadas) y la economía (por ejemplo, equilibrando las recompensas de staking de BTC entre muchas cadenas consumidoras para que sea atractivo para los poseedores de BTC sin subsidiar en exceso). Un desarrollo interesante es el soporte de Babylon para cosas como la cobertura de Nexus Mutual (según una publicación de mayo de 2025) para ofrecer un seguro sobre el slashing del staking de BTC, lo que podría atraer aún más a los participantes. Esto muestra que el ecosistema está madurando en torno a la gestión de riesgos para este nuevo paradigma.

Discusiones Comunitarias y entre Proyectos: A partir de 2025, se está llevando a cabo una conversación más amplia sobre el futuro de la seguridad compartida en el mundo cripto. La comunidad de Ethereum en gran medida da la bienvenida a EigenLayer pero se mantiene cautelosa; la publicación del blog de Vitalik (mayo de 2023) marcó la pauta para una delineación cuidadosa de lo que es aceptable. EigenLayer se relaciona regularmente con la comunidad a través de su foro, abordando preguntas como "¿Está EigenLayer sobrecargando el consenso de Ethereum?" (respuesta corta: argumentan que no, debido a las salvaguardas de diseño). En la comunidad de Cosmos, Babylon generó entusiasmo ya que potencialmente resuelve problemas de seguridad de larga data (p. ej., zonas pequeñas que sufren ataques del 51%) sin requerir que se unan a un centro de seguridad compartida como Polkadot o el ICS de Cosmos Hub. También hay una interesante convergencia: algunos en Cosmos se preguntan si el staking de Ethereum podría alguna vez potenciar las cadenas de Cosmos (que es más el dominio de EigenLayer), mientras que en Ethereum se preguntan si el staking de Bitcoin podría asegurar los rollups de Ethereum (el concepto de Babylon). Estamos viendo los primeros signos de polinización cruzada: por ejemplo, ideas de usar EigenLayer para hacer restake de ETH en cadenas no Ethereum (Symbiotic y Karak son pasos en esa dirección) y usar el staking de BTC de Babylon como una opción para las L2 de Ethereum. Incluso Solana tiene un proyecto de restaking (Solayer) que lanzó una prueba suave y alcanzó los límites rápidamente, mostrando que el interés abarca múltiples ecosistemas.

Desarrollos de gobernanza en estos proyectos incluyen una creciente representación comunitaria. El consejo de EigenLayer ahora incluye miembros externos de la comunidad, y ha financiado subvenciones (a través de la Fundación Eigen) a los desarrolladores del núcleo de Ethereum, señalando buena voluntad hacia el núcleo de Ethereum. Es probable que la gobernanza de Karak gire en torno al token KAR; actualmente, ejecutan un sistema de XP fuera de la cadena, pero se puede esperar una DAO más formal una vez que KAR sea líquido. La gobernanza de Babylon será crucial ya que coordina entre Bitcoin (que no tiene gobernanza formal) y las cadenas de Cosmos (que tienen gobernanza en la cadena). Estableció una Fundación Babylon y un foro comunitario para discutir parámetros como los períodos de desvinculación para BTC, que requieren una alineación cuidadosa con las restricciones de Bitcoin.

En resumen, para mediados de 2025, el mercado de restaking y seguridad compartida ha pasado de la teoría a la práctica. EigenLayer está completamente operativo con servicios reales y slashing, probando el modelo en Ethereum. Karak ha introducido una variante multi-cadena convincente, ampliando el espacio de diseño y apuntando a nuevos activos. Babylon ha demostrado que incluso Bitcoin puede unirse a la fiesta de la seguridad compartida a través de una criptografía ingeniosa, abordando un segmento completamente diferente del mercado. El ecosistema es vibrante: están surgiendo nuevos competidores (p. ej., Symbiotic en Ethereum, Solayer en Solana, BounceBit usando BTC custodiado), cada uno experimentando con diferentes compensaciones (Symbiotic alineándose con Lido para usar stETH y cualquier ERC-20, BounceBit adoptando un enfoque regulado con BTC envuelto, etc.). Este panorama competitivo está impulsando una rápida innovación y, lo que es más importante, una discusión sobre estándares y seguridad. Los foros comunitarios y los grupos de investigación están debatiendo activamente preguntas como: ¿Debería haber límites en el stake en restaking por operador? ¿Cómo implementar mejor las pruebas de slashing entre cadenas? ¿Podría el restaking aumentar involuntariamente la correlación sistémica entre cadenas? Todo esto se está estudiando. Los modelos de gobernanza también están evolucionando: el paso de EigenLayer a un consejo semi-descentralizado es un ejemplo de equilibrio entre agilidad y seguridad en la gobernanza.

Mirando hacia el futuro, el paradigma del restaking está preparado para convertirse en una base de la infraestructura Web3, de manera muy similar a como los servicios en la nube se volvieron esenciales en la Web2. Al mercantilizar la seguridad, permite que los proyectos más pequeños se lancen con confianza y que los proyectos más grandes optimicen el uso de su capital. Los desarrollos hasta 2025 muestran una trayectoria prometedora pero cautelosa: la tecnología funciona y está escalando, pero todos los actores son conscientes de los riesgos. Con los desarrolladores del núcleo de Ethereum, los constructores de Cosmos e incluso los Bitcoiners ahora involucrados en iniciativas de seguridad compartida, está claro que este mercado solo crecerá. Podemos esperar una colaboración más estrecha entre ecosistemas (quizás fondos de seguridad conjuntos o pruebas de slashing estandarizadas) e, inevitablemente, claridad regulatoria a medida que los reguladores se pongan al día con estas construcciones multi-cadena y multi-activo. Mientras tanto, los investigadores y desarrolladores tienen un tesoro de nuevos datos de EigenLayer, Karak, Babylon y otros para analizar y mejorar, asegurando que la "revolución del restaking" continúe de una manera segura y sostenible.

Fuentes:

1. EigenLayer documentation and whitepaper – definition of restaking and AVS
2. Coinbase Cloud blog (May 2024) – EigenLayer overview, roles of restakers/operators/AVSs
3. Blockworks News (April 2024) – Karak founders on “universal restaking” vs EigenLayer
4. Ditto research (2023) – Comparison of EigenLayer, Symbiotic, Karak asset support
5. Messari Research (Apr 2024) – “Babylon: Bitcoin Shared Security”, BTC staking mechanism
6. HashKey Research (Jul 2024) – Babylon vs EigenLayer restaking yields
7. EigenLayer Forum (Dec 2024) – Discussion of Vitalik’s “Don’t overload Ethereum’s consensus” and EigenLayer’s approach
8. Blockworks News (Apr 2024) – Chorus One report on EigenLayer risks (slashing cascade, centralization)
9. Kairos Research (Oct 2023) – EigenLayer AVS overview and regulatory risk note
10. EigenCloud Blog (Jan 2025) – “2024 Year in Review” (EigenLayer stats, governance updates)
11. Blockworks News (Apr 2024) – Karak launch coverage and asset support
12. Babylon Labs Blog (May 2025) – “Phase-2 launch round-up” (Bitcoin staking live, 50k BTC staked)
13. Bankless (May 2024) – “The Restaking Competition” (EigenLayer vs Karak vs others)
14. Vitalik Buterin, “Don’t Overload Ethereum’s Consensus”, May 2023 – Guidance on validator reuse vs social consensus
15. Coinbase Developer Guide (Apr 2024) – Technical details on EigenLayer operation (EigenPods, delegation, AVS structure).

¿La revolución de velocidad que Ethereum ha estado esperando?​

En el mundo de alta presión de las soluciones de escalado de blockchain, ha surgido un nuevo contendiente que está generando tanto entusiasmo como controversia. MegaETH se está posicionando como la respuesta de Ethereum a cadenas ultra‑rápidas como Solana, prometiendo latencia sub‑milisegundo y asombrosos 100,000 transacciones por segundo (TPS).

Pero estas afirmaciones vienen con importantes compromisos. MegaETH está haciendo sacrificios calculados para “Make Ethereum Great Again”, planteando preguntas cruciales sobre el equilibrio entre rendimiento, seguridad y descentralización.

Como proveedores de infraestructura que hemos visto muchas soluciones prometedoras ir y venir, en BlockEden.xyz hemos realizado este análisis para ayudar a desarrolladores y constructores a entender qué hace a MegaETH único — y qué riesgos considerar antes de construir sobre ella.

¿Qué hace a MegaETH diferente?​

MegaETH es una solución de capa-2 para Ethereum que ha reinventado la arquitectura de blockchain con un enfoque singular: rendimiento en tiempo real.

Mientras que la mayoría de las L2 mejoran los 15 TPS de Ethereum en un factor de 10‑100×, MegaETH apunta a una mejora de 1,000‑10,000× — velocidades que la colocarían en una categoría propia.

Enfoque técnico revolucionario​

MegaETH logra su velocidad extraordinaria mediante decisiones de ingeniería radicales:

1. Arquitectura de secuenciador único: A diferencia de la mayoría de las L2 que usan múltiples secuenciadores o planean descentralizarlos, MegaETH utiliza un solo secuenciador para ordenar transacciones, eligiendo deliberadamente el rendimiento sobre la descentralización.

2. Trie de estado optimizado: Un sistema de almacenamiento de estado completamente rediseñado que puede manejar datos de estado a nivel de terabytes de forma eficiente, incluso en nodos con RAM limitada.

3. Compilación JIT de bytecode: Compilación just‑in‑time del bytecode de contratos inteligentes de Ethereum, acercando la ejecución a la velocidad “bare‑metal”.

4. Pipeline de ejecución paralela: Un enfoque multinúcleo que procesa transacciones en flujos paralelos para maximizar el rendimiento.

5. Micro‑bloques: Objetivo de tiempos de bloque de 1 ms mediante producción continua de bloques “streaming” en lugar de procesamiento por lotes.

6. Integración EigenDA: Uso de la solución de disponibilidad de datos de EigenLayer en lugar de publicar todos los datos en Ethereum L1, reduciendo costos mientras se mantiene la seguridad mediante validación alineada con Ethereum.

Esta arquitectura entrega métricas de rendimiento que parecen casi imposibles para una blockchain:

• Latencia sub‑milisegundo (objetivo 10 ms)
• Más de 100,000 TPS de rendimiento
• Compatibilidad con EVM para facilitar la portación de aplicaciones

Probando las afirmaciones: Estado actual de MegaETH​

A marzo de 2025, la testnet pública de MegaETH está en funcionamiento. El despliegue inicial comenzó el 6 de marzo con un lanzamiento por fases, empezando con socios de infraestructura y equipos de dApp antes de abrirse a una incorporación más amplia de usuarios.

Las métricas tempranas de la testnet muestran:

• 1.68 Giga‑gas por segundo de rendimiento
• Tiempos de bloque de 15 ms (significativamente más rápidos que otras L2)
• Soporte para ejecución paralela que eventualmente impulsará el rendimiento aún más

El equipo ha indicado que la testnet funciona en modo algo limitado, con planes de habilitar paralelismo adicional que podría duplicar el rendimiento de gas a alrededor de 3.36 Ggas/seg, avanzando hacia su objetivo final de 10 Ggas/seg (10 mil millones de gas por segundo).

Modelo de seguridad y confianza​

El enfoque de seguridad de MegaETH representa una desviación significativa de la ortodoxia de blockchain. A diferencia del diseño de confianza mínima de Ethereum con miles de nodos validadores, MegaETH adopta una capa de ejecución centralizada con Ethereum como respaldo de seguridad.

Filosofía “Can’t Be Evil”​

MegaETH emplea un modelo de rollup optimista con características únicas:

1. Sistema de pruebas de fraude: Al igual que otros rollups optimistas, MegaETH permite a observadores desafiar transiciones de estado inválidas mediante pruebas de fraude enviadas a Ethereum.

2. Nodos verificadores: Nodos independientes replican los cálculos del secuenciador y generarían pruebas de fraude si se detectan discrepancias.

3. Liquidación en Ethereum: Todas las transacciones se liquidan finalmente en Ethereum, heredando su seguridad para el estado final.

Esto crea lo que el equipo llama un mecanismo “can’t be evil”: el secuenciador no puede producir bloques inválidos o alterar el estado incorrectamente sin ser detectado y castigado.

Compromiso de centralización​

El aspecto controvertido: MegaETH opera con un único secuenciador y explícitamente “no tiene planes de descentralizar el secuenciador”. Esto genera dos riesgos significativos:

1. Riesgo de disponibilidad: Si el secuenciador se desconecta, la red podría detenerse hasta que se recupere o se nombre un nuevo secuenciador.

2. Riesgo de censura: El secuenciador podría censurar ciertas transacciones o usuarios a corto plazo (aunque los usuarios podrían salir finalmente a L1).

MegaETH argumenta que estos riesgos son aceptables porque:

• La L2 está anclada a Ethereum para la seguridad final
• La disponibilidad de datos es manejada por múltiples nodos en EigenDA
• Cualquier censura o fraude puede ser visto y desafiado por la comunidad

Casos de uso: Cuando la ejecución ultra‑rápida importa​

Las capacidades en tiempo real de MegaETH desbloquean casos de uso que antes eran imprácticos en blockchains más lentas:

1. Trading de alta frecuencia y DeFi​

MegaETH permite DEX con ejecución casi instantánea y actualizaciones de libro de órdenes. Proyectos que ya están construyendo incluyen:

• GTE: Un DEX spot en tiempo real que combina libros de órdenes centralizados y liquidez AMM
• Teko Finance: Un mercado de dinero para préstamos apalancados con actualizaciones rápidas de margen
• Cap: Un stablecoin y motor de rendimiento que arbitra entre mercados
• Avon: Un protocolo de préstamo con emparejamiento de préstamos basado en libro de órdenes

Estas aplicaciones DeFi se benefician del rendimiento de MegaETH para operar con deslizamiento mínimo y actualizaciones de alta frecuencia.

2. Juegos y metaverso​

La finalización sub‑segundo hace viables los juegos totalmente on‑chain sin esperar confirmaciones:

• Awe: Un juego 3D de mundo abierto con acciones on‑chain
• Biomes: Un metaverso on‑chain similar a Minecraft
• Mega Buddies y Mega Cheetah: Series de avatares coleccionables

Estas aplicaciones pueden ofrecer retroalimentación en tiempo real en juegos blockchain, habilitando jugabilidad rápida y batallas PvP on‑chain.

3. Aplicaciones empresariales​

El rendimiento de MegaETH la hace adecuada para aplicaciones empresariales que requieren alto rendimiento:

• Infraestructura de pagos instantáneos
• Sistemas de gestión de riesgos en tiempo real
• Verificación de cadena de suministro con finalización inmediata
• Sistemas de subastas de alta frecuencia

La ventaja clave en todos estos casos es la capacidad de ejecutar aplicaciones intensivas en cómputo con retroalimentación inmediata, manteniéndose conectadas al ecosistema de Ethereum.

El equipo detrás de MegaETH​

MegaETH fue co‑fundada por un equipo con credenciales impresionantes:

• Li Yilong: PhD en ciencias de la computación de Stanford especializado en sistemas de computación de baja latencia
• Yang Lei: PhD del MIT investigando sistemas descentralizados y conectividad con Ethereum
• Shuyao Kong: Ex Jefe de Desarrollo de Negocios Globales en ConsenSys

El proyecto ha atraído a inversores destacados, incluidos los co‑fundadores de Ethereum Vitalik Buterin y Joseph Lubin como inversores ángeles. La participación de Vitalik es particularmente notable, ya que rara vez invierte en proyectos específicos.

Otros inversores incluyen Sreeram Kannan (fundador de EigenLayer), firmas de capital de riesgo como Dragonfly Capital, Figment Capital y Robot Ventures, y figuras influyentes de la comunidad como Cobie.

Estrategia de token: Enfoque NFT Soulbound​

MegaETH introdujo un método innovador de distribución de tokens mediante “NFTs soulbound” llamados “The Fluffle”. En febrero de 2025, crearon 10,000 NFTs no transferibles que representan al menos el 5 % del suministro total de tokens MegaETH.

Aspectos clave de la tokenomía:

• 5,000 NFTs se vendieron a 1 ETH cada uno (recaudando $13‑14 millones)
• Los otros 5,000 NFTs fueron asignados a proyectos del ecosistema y constructores
• Los NFTs son soulbound (no pueden transferirse), asegurando alineación a largo plazo
• Valoración implícita de alrededor de $540 millones, extremadamente alta para un proyecto pre‑lanzamiento
• El equipo ha recaudado aproximadamente $30‑40 millones en financiación de riesgo

Eventualmente, se espera que el token MegaETH sirva como moneda nativa para tarifas de transacción y posiblemente para staking y gobernanza.

Comparación de MegaETH con competidores​

vs. Otras L2 de Ethereum​

Comparada con Optimism, Arbitrum y Base, MegaETH es significativamente más rápida pero hace compromisos mayores en descentralización:

• Rendimiento: MegaETH apunta a más de 100,000 TPS vs. los tiempos de transacción de 250 ms de Arbitrum y menor rendimiento
• Descentralización: MegaETH usa un único secuenciador vs. los planes de otras L2 de descentralizar sus secuenciadores
• Disponibilidad de datos: MegaETH usa EigenDA vs. otras L2 que publican datos directamente en Ethereum

vs. Solana y L1 de alto rendimiento​

MegaETH busca “superar a Solana en su propio juego” mientras aprovecha la seguridad de Ethereum:

• Rendimiento: MegaETH apunta a 100k+ TPS vs. los 65k TPS teóricos de Solana (normalmente unos pocos miles en la práctica)
• Latencia: MegaETH ~10 ms vs. la finalidad de ~400 ms de Solana
• Descentralización: MegaETH tiene 1 secuenciador vs. los ~1,900 validadores de Solana

vs. ZK‑Rollups (StarkNet, zkSync)​

Mientras los ZK‑rollups ofrecen garantías de seguridad más fuertes mediante pruebas de validez:

• Velocidad: MegaETH brinda una experiencia de usuario más rápida sin esperar la generación de pruebas ZK
• Confianza: Los ZK‑rollups no requieren confiar en la honestidad de un secuenciador, proporcionando mayor seguridad
• Planes futuros: MegaETH podría integrar pruebas ZK, convirtiéndose en una solución híbrida

El posicionamiento de MegaETH es claro: es la opción más rápida dentro del ecosistema Ethereum, sacrificando algo de descentralización para lograr velocidades similares a Web2.

Perspectiva de infraestructura: Qué deben considerar los constructores​

Como proveedor de infraestructura que conecta a desarrolladores con nodos blockchain, BlockEden.xyz ve tanto oportunidades como desafíos en el enfoque de MegaETH:

Beneficios potenciales para los constructores​

1. Experiencia de usuario excepcional: Las aplicaciones pueden ofrecer retroalimentación instantánea y alto rendimiento, creando una respuesta similar a Web2.
2. Compatibilidad con EVM: Las dApps existentes en Ethereum pueden migrar con cambios mínimos, desbloqueando rendimiento sin reescrituras.
3. Eficiencia de costos: El alto rendimiento implica costos por transacción más bajos para usuarios y aplicaciones.
4. Respaldo de seguridad de Ethereum: A pesar de la centralización en la capa de ejecución, la liquidación en Ethereum brinda una base de seguridad.

Consideraciones de riesgo​

1. Punto único de falla: El secuenciador centralizado crea riesgo de disponibilidad; si se cae, tu aplicación también.
2. Vulnerabilidad a censura: Las aplicaciones podrían enfrentar censura de transacciones sin recurso inmediato.
3. Tecnología en etapa temprana: La arquitectura novedosa de MegaETH no ha sido probada a gran escala con valor real.
4. Dependencia de EigenDA: Utilizar una solución de disponibilidad de datos más nueva añade una suposición de confianza adicional.

Requisitos de infraestructura​

Apoyar el rendimiento de MegaETH requerirá infraestructura robusta:

• Nodos RPC de alta capacidad capaces de manejar el flujo masivo de datos
• Soluciones avanzadas de indexado para acceso a datos en tiempo real
• Monitoreo especializado para la arquitectura única
• Vigilancia fiable de puentes para operaciones cross‑chain

Conclusión: ¿Revolución o compromiso?​

MegaETH representa un experimento audaz en escalado de blockchain, que prioriza deliberadamente el rendimiento sobre la descentralización. Si este enfoque tendrá éxito dependerá de si el mercado valora más la velocidad que la ejecución descentralizada.

Los próximos meses serán críticos mientras MegaETH pasa de testnet a mainnet. Si cumple sus promesas de rendimiento manteniendo suficiente seguridad, podría redefinir nuestra visión del escalado de blockchain. Si tropieza, reforzará por qué la descentralización sigue siendo un valor central de blockchain.

Por ahora, MegaETH se posiciona como una de las soluciones de escalado de Ethereum más ambiciosas hasta la fecha. Su disposición a desafiar la ortodoxia ya ha generado conversaciones importantes sobre qué compromisos son aceptables en la búsqueda de una adopción masiva de blockchain.

En BlockEden.xyz, estamos comprometidos a apoyar a los desarrolladores donde sea que construyan, incluidas redes de alto rendimiento como MegaETH. Nuestra infraestructura de nodos fiable y nuestros servicios API están diseñados para ayudar a que las aplicaciones prosperen en todo el ecosistema multichain, sin importar qué enfoque de escalado prevalezca al final.

¿Quieres construir sobre MegaETH o necesitas infraestructura de nodos fiable para aplicaciones de alto rendimiento? Correo de contacto: info@BlockEden.xyz para conocer cómo podemos apoyar tu desarrollo con nuestra garantía de disponibilidad del 99.9 % y servicios RPC especializados en más de 27 blockchains.

El problema de escalado de Web3​

La industria de blockchain enfrenta un desafío persistente: ¿cómo escalar para soportar millones de usuarios sin sacrificar seguridad ni descentralización?

Ethereum, la principal plataforma de contratos inteligentes, procesa aproximadamente 15 transacciones por segundo en su capa base. Durante periodos de alta demanda, esta limitación ha generado tarifas de gas exorbitantes —a veces superiores a 100 USD por transacción durante minting de NFT o frenéticas rondas de farming en DeFi.

Este cuello de botella de escalado representa una amenaza existencial para la adopción de Web3. Los usuarios acostumbrados a la respuesta instantánea de las aplicaciones Web2 no tolerarán pagar 50 USD y esperar 3 minutos solo para intercambiar tokens o crear un NFT.

Entra la solución que está remodelando rápidamente la arquitectura de blockchain: Rollups-as-a-Service (RaaS).

Entendiendo Rollups-as-a-Service (RaaS)​

Las plataformas RaaS permiten a los desarrolladores desplegar sus propios rollups personalizados sin la complejidad de construir todo desde cero. Estos servicios convierten lo que normalmente requeriría un equipo de ingeniería especializado y meses de desarrollo en un proceso simplificado, a veces con un solo clic.

¿Por qué importa? Porque los rollups son la clave para escalar blockchain.

Los rollups funcionan al:

• Procesar transacciones fuera de la cadena principal (Capa 1)
• Agrupar esas transacciones en lotes
• Enviar pruebas comprimidas de esas transacciones de vuelta a la cadena principal

¿El resultado? Aumento drástico del rendimiento y reducción significativa de costos mientras se hereda la seguridad de la cadena de bloques subyacente (como Ethereum).

"Los rollups no compiten con Ethereum — los extienden. Son como carriles exprés especializados construidos sobre la autopista de Ethereum."

Este enfoque de escalado es tan prometedor que Ethereum adoptó oficialmente una "hoja de ruta centrada en rollups" en 2020, reconociendo que el futuro no será una única cadena monolítica, sino un ecosistema de rollups interconectados y diseñados para propósitos específicos.

Caldera: Liderando la revolución RaaS​

Entre los proveedores emergentes de RaaS, Caldera destaca como pionero. Fundada en 2023 y con una recaudación de 25 M USD de inversores prominentes como Dragonfly, Sequoia Capital y Lattice, Caldera se ha posicionado rápidamente como un proveedor de infraestructura líder en el espacio de rollups.

¿Qué hace a Caldera diferente?​

Caldera se diferencia en varios aspectos clave:

1. Soporte multimarco: A diferencia de competidores que se centran en un solo marco de rollup, Caldera soporta los principales marcos como OP Stack de Optimism y la tecnología Orbit/Nitro de Arbitrum, ofreciendo a los desarrolladores flexibilidad en su enfoque técnico.

2. Infraestructura de extremo a extremo: Cuando despliegas con Caldera, obtienes un conjunto completo de componentes: nodos RPC confiables, exploradores de bloques, servicios de indexación e interfaces de puentes.

3. Ecosistema de integración rico: Caldera viene preintegrada con más de 40 herramientas y servicios Web3, incluidos oráculos, faucets, wallets y puentes cross‑chain (LayerZero, Axelar, Wormhole, Connext, entre otros).

4. Red Metalayer: Tal vez la innovación más ambiciosa de Caldera sea su Metalayer, una red que conecta todos los rollups impulsados por Caldera en un ecosistema unificado, permitiendo compartir liquidez y mensajes sin fricciones.

5. Soporte multivirtual machine: A finales de 2024, Caldera se convirtió en el primer RaaS en soportar la Solana Virtual Machine (SVM) sobre Ethereum, habilitando cadenas de alto rendimiento al estilo Solana que aún se asientan en la capa base segura de Ethereum.

El enfoque de Caldera está creando lo que llaman una "capa de todo" para rollups — una red cohesiva donde diferentes rollups pueden interoperar en lugar de existir como islas aisladas.

Adopción en el mundo real: ¿Quién está usando Caldera?​

Caldera ha ganado una tracción significativa, con más de 75 rollups en producción a finales de 2024. Algunos proyectos destacados incluyen:

• Manta Pacific: Una red altamente escalable para desplegar aplicaciones de conocimiento cero que utiliza el OP Stack de Caldera combinado con Celestia para disponibilidad de datos.

• RARI Chain: El rollup enfocado en NFT de Rarible que procesa transacciones en menos de un segundo y aplica regalías de NFT a nivel de protocolo.

• Kinto: Una plataforma DeFi regulatoriamente compliant con KYC/AML on‑chain y capacidades de abstracción de cuentas.

• inEVM de Injective: Un rollup compatible con EVM que extiende la interoperabilidad de Injective, conectando el ecosistema Cosmos con dApps basadas en Ethereum.

Estos proyectos demuestran cómo los rollups específicos de aplicación permiten personalizaciones imposibles en las cadenas de capa 1 de propósito general. A finales de 2024, los rollups colectivos de Caldera habrían procesado más de 300 millones de transacciones para más de 6 millones de wallets únicas, con casi 1 mil millones de dólares en valor total bloqueado (TVL).

Comparativa RaaS: Caldera vs. Competidores​

El panorama RaaS se vuelve cada vez más competitivo, con varios jugadores notables:

Conduit​

• Se enfoca exclusivamente en los ecosistemas de Optimism y Arbitrum
• Prioriza una experiencia totalmente autoservicio y sin código
• Alimenta aproximadamente el 20 % de los rollups de la mainnet de Ethereum, incluido Zora

AltLayer​

• Ofrece "Flashlayers" — rollups desechables y bajo demanda para necesidades temporales
• Se centra en escalado elástico para eventos específicos o periodos de alto tráfico
• Demostró un rendimiento impresionante durante eventos de gaming (más de 180 000 transacciones diarias)

Sovereign Labs​

• Construye un SDK de Rollup enfocado en tecnologías de conocimiento cero
• Busca habilitar ZK‑rollups en cualquier cadena base, no solo en Ethereum
• Aún en desarrollo, posicionándose para la próxima ola de despliegues ZK multichain

Si bien estos competidores sobresalen en nichos específicos, el enfoque integral de Caldera —que combina una red de rollups unificada, soporte multivirtual machine y una fuerte orientación a la experiencia del desarrollador— la ha consolidado como líder de mercado.

El futuro de RaaS y el escalado de blockchain​

RaaS está preparado para remodelar el panorama de blockchain de maneras profundas:

1. Proliferación de cadenas específicas de aplicación​

Investigaciones de la industria sugieren que nos dirigimos a un futuro con potencialmente millones de rollups, cada uno sirviendo a aplicaciones o comunidades concretas. Con RaaS reduciendo las barreras de despliegue, cada dApp importante podría contar con su propia cadena optimizada.

2. Interoperabilidad como desafío crítico​

A medida que los rollups se multiplican, la capacidad de comunicarse y compartir valor entre ellos se vuelve crucial. El Metalayer de Caldera representa un intento temprano de resolver este reto —creando una experiencia unificada a través de una red de rollups.

3. De cadenas aisladas a ecosistemas interconectados​

El objetivo final es una experiencia multichain fluida donde los usuarios apenas necesiten saber en qué cadena están. Valor y datos fluirían libremente a través de una telaraña interconectada de rollups especializados, todos asegurados por robustas redes de capa 1.

4. Infraestructura de blockchain al estilo cloud​

RaaS está convirtiendo efectivamente la infraestructura de blockchain en un servicio tipo cloud. El "Rollup Engine" de Caldera permite actualizaciones dinámicas y componentes modulares, tratando a los rollups como servicios configurables en la nube que pueden escalar bajo demanda.

Qué significa esto para desarrolladores y BlockEden.xyz​

En BlockEden.xyz vemos un enorme potencial en la revolución RaaS. Como proveedor de infraestructura que conecta a los desarrolladores con nodos de blockchain de forma segura, estamos posicionados para jugar un papel crucial en este paisaje en evolución.

La proliferación de rollups implica que los desarrolladores necesiten infraestructura de nodos confiable más que nunca. Un futuro con miles de cadenas específicas de aplicación demanda servicios RPC robustos y de alta disponibilidad —exactamente lo que BlockEden.xyz se especializa en ofrecer.

Nos entusiasman particularmente las oportunidades en:

1. Servicios RPC especializados para rollups: A medida que los rollups adoptan características y optimizaciones únicas, la infraestructura especializada se vuelve esencial.

2. Indexación de datos cross‑chain: Con valor fluyendo entre múltiples rollups, los desarrolladores requieren herramientas para rastrear y analizar actividades intercadena.

3. Herramientas de desarrollo mejoradas: Conforme el despliegue de rollups se simplifica, crece la necesidad de herramientas sofisticadas de monitoreo, depuración y analítica.

4. Acceso API unificado: Los desarrolladores que trabajan en varios rollups necesitan un acceso simplificado y unificado a diversas redes blockchain.

Conclusión: El futuro modular de blockchain​

El auge de Rollups-as-a-Service representa un cambio fundamental en cómo pensamos el escalado de blockchain. En lugar de forzar a todas las aplicaciones a una única cadena, nos dirigimos a un futuro modular con cadenas especializadas para casos de uso concretos, todas interconectadas y aseguradas por redes de capa 1 robustas.

El enfoque de Caldera —creando una red unificada de rollups con liquidez compartida y mensajería fluida— ofrece una visión de ese futuro. Al hacer que el despliegue de rollups sea tan sencillo como lanzar un servidor en la nube, los proveedores RaaS están democratizando el acceso a la infraestructura blockchain.

En BlockEden.xyz, estamos comprometidos a apoyar esta evolución proporcionando la infraestructura de nodos confiable y las herramientas de desarrollo necesarias para construir en este futuro multichain. Como solemos decir, el futuro de Web3 no es una sola cadena — son miles de cadenas especializadas trabajando juntas.

¿Quieres construir sobre un rollup o necesitas infraestructura de nodos confiable para tu proyecto blockchain? Correo de contacto: info@BlockEden.xyz para descubrir cómo podemos apoyar tu desarrollo con nuestra garantía de 99,9 % de tiempo activo y servicios RPC especializados en más de 27 blockchains.

Durante años, el Ethereum Name Service (ENS) fue visto por muchos como una herramienta de nicho para entusiastas de las criptomonedas: una forma de reemplazar las direcciones de billeteras largas y torpes con nombres legibles .eth. Pero en 2025, esa percepción está desactualizada. ENS ha evolucionado hasta convertirse en una capa fundamental para la identidad de marca programable, transformando un simple nombre en un ancla portátil, verificable y unificado para toda la presencia digital de tu empresa.

Ya no se trata solo de marca.eth. Se trata de hacer que marca.com sea consciente de las criptomonedas, emitir roles verificables a empleados y construir confianza con los clientes a través de una única fuente canónica de verdad. Esta es la guía para empresas sobre por qué ENS ahora importa y cómo implementarlo hoy.

Resumen

• ENS convierte un nombre (por ejemplo, marca.eth o marca.com) en una identidad programable que mapea a billeteras, aplicaciones, sitios web y datos de perfil verificados.
• No tienes que abandonar tu dominio DNS: con DNSSEC sin Gas, un marca.com puede funcionar como un nombre ENS sin tarifas en cadena en la configuración.
• Los precios de .eth son transparentes y basados en renovación (los nombres más cortos cuestan más), y los ingresos financian el protocolo de bien público a través del ENS DAO.
• Los subnombres como alice.marca.eth o support.marca.com te permiten emitir roles, beneficios y acceso, limitados en tiempo y restringidos por "fusibles" de NameWrapper y expiración.
• ENS está moviendo la funcionalidad central a L2 en ENSv2, con resolución minimizada de confianza a través de CCIP‑Read: importante para costo, velocidad y escala.

Por Qué ENS Importa para las Empresas Modernas​

Para las empresas, la identidad está fragmentada. Tienes un nombre de dominio para tu sitio web, cuentas de redes sociales para marketing y cuentas separadas para pagos y operaciones. ENS ofrece una manera de unificar estas, creando una capa de identidad única y autoritativa.

• Identidad Unificada y Legible: En su núcleo, ENS mapea un nombre memorable a direcciones criptográficas. Pero su poder se extiende mucho más allá de una sola blockchain. Con soporte multicadena, tu marca.eth puede apuntar simultáneamente a tu tesorería de Bitcoin, billetera de operaciones de Solana y contratos inteligentes de Ethereum. El nombre de tu marca se convierte en el ancla única y fácil de usar para pagos, aplicaciones y perfiles en todo el ecosistema web3.

• Integración Profunda del Ecosistema: ENS no es una apuesta especulativa en un protocolo de nicho; es una primitiva web3. Es compatible nativamente en billeteras principales (Coinbase Wallet, MetaMask), navegadores (Brave, Opera) y aplicaciones descentralizadas (Uniswap, Aave). Cuando socios como GoDaddy integran ENS, señala una convergencia entre la infraestructura web2 y web3. Al adoptar ENS, estás conectando tu marca a una red vasta e interoperable.

• Datos de Perfil Ricos y Verificables: Más allá de las direcciones, los nombres ENS pueden almacenar registros de texto estandarizados para información de perfil como avatar, email, cuentas de redes sociales y URL del sitio web. Esto convierte tu nombre ENS en una tarjeta de presentación canónica y legible por máquina. Tus herramientas de soporte, marketing e ingeniería pueden todas extraer de la misma fuente verificada, asegurando consistencia y construyendo confianza con tus usuarios.

Dos Entradas: .eth vs. "Trae Tu Propio DNS"​

Comenzar con ENS es flexible, ofreciendo dos rutas principales que pueden y deben usarse juntas.

1. Registrar marca.eth​

Este es el enfoque nativo de web3. Registrar un nombre .eth te da un activo cripto-nativo que señala el compromiso de tu marca con el ecosistema. El proceso es directo y transparente.

• Cronograma de Tarifas Claro: Las tarifas se pagan anualmente en ETH para prevenir la especulación y financiar el protocolo. Los precios se basan en la escasez: nombres de 5+ caracteres cuestan solo $5/año, nombres de 4 caracteres$160/año, y nombres de 3 caracteres $640/año.
• Establecer un Nombre Primario: Una vez que poseas marca.eth, debes establecerlo como el "Nombre Primario" (también conocido como registro inverso) para la billetera principal de tu empresa. Este es un paso crítico que permite que las billeteras y dapps muestren tu nombre memorable en lugar de tu dirección larga, mejorando dramáticamente la experiencia del usuario y la confianza.

2. Mejorar marca.com Dentro de ENS (No Se Requiere Migración)​

No necesitas abandonar tu valioso dominio web2. Gracias a una función llamada DNSSEC sin Gas, puedes vincular tu dominio DNS existente a una billetera cripto, actualizándolo efectivamente a un nombre ENS completamente funcional.

• Costo Cero en Cadena para Propietarios: El proceso permite que un marca.com se vuelva resoluble dentro del ecosistema ENS sin requerir que el propietario del dominio envíe una transacción en cadena.
• Soporte de Registradores Convencionales: GoDaddy ya ha simplificado esto con un registro "Crypto Wallet" de un clic, impulsado por esta función ENS. Otros registradores principales que soportan DNSSEC también pueden configurarse para trabajar con ENS.

Consejo pragmático: Haz ambos. Usa marca.eth para tu audiencia nativa web3 y operaciones de tesorería. Simultáneamente, trae marca.com a ENS para unificar toda tu huella de marca y proporcionar un puente fluido para tu base de usuarios existente.

Implementación Cero-a-Uno: Un Plan de Una Semana​

Desplegar ENS no tiene que ser un proyecto de múltiples trimestres. Un equipo enfocado puede establecer una presencia robusta en aproximadamente una semana.

• Día 1–2: Nombre y Política Reclama marca.eth y vincula tu nombre DNS existente usando el método DNSSEC sin Gas. Este es también el momento para establecer una política interna sobre ortografía canónica, uso de emojis y reglas de normalización. ENS usa un estándar llamado ENSIP-15 para manejar variaciones de nombres, pero es crucial estar consciente de los homóglifos (caracteres que se ven similares) para prevenir ataques de phishing contra tu marca.

• Día 3: Nombres Primarios y Billeteras Para la tesorería, operaciones y billeteras de pago de tu empresa, establece el Nombre Primario (registro inverso) para que resuelvan a treasury.marca.eth o un nombre similar. Usa esta oportunidad para poblar registros de direcciones multi-moneda (BTC, SOL, etc.) para asegurar que los pagos enviados a tu nombre ENS se enruten correctamente, sin importar la cadena.

• Día 4: Datos de Perfil Completa los registros de texto estandarizados en tu nombre ENS primario. Como mínimo, establece email, url, com.twitter y avatar. Un avatar oficial añade verificación visual inmediata en billeteras compatibles. Para seguridad mejorada, también puedes añadir una clave PGP pública.

• Día 5: Subnombres Comienza emitiendo subnombres como alice.marca.eth para empleados o support.marca.com para departamentos. Usa el NameWrapper para aplicar "fusibles" de seguridad que pueden, por ejemplo, prevenir que el subnombre sea transferido. Establece una fecha de expiración para revocar automáticamente el acceso cuando termine un contrato o se vaya un empleado.

• Día 6: Sitio Web / Documentos Descentraliza tu presencia web. Ancla tu kit de prensa, términos de servicio o una página de estado a una red de almacenamiento descentralizada como IPFS o Arweave y vincúlala a tu nombre ENS a través del registro contenthash. Para acceso universal, los usuarios pueden resolver este contenido a través de pasarelas públicas como eth.limo.

• Día 7: Integrar en el Producto Comienza usando ENS en tu propia aplicación. Usa librerías como viem con ensjs para resolver nombres, normalizar entradas de usuario y mostrar avatares. Al buscar direcciones, realiza una búsqueda inversa para mostrar el Nombre Primario del usuario. Asegúrate de usar una pasarela de resolución que soporte CCIP-Read para asegurar que tu aplicación esté preparada para el futuro con la arquitectura L2 de ENSv2.

Patrones Comunes Que Rinden Rápido​

Una vez configurado, ENS desbloquea casos de uso poderosos y prácticos que entregan valor inmediato.

• Pagos Más Seguros y Simples: En lugar de copiar y pegar una dirección larga y propensa a errores, pon pay.marca.eth en tus facturas. Al publicar todas tus direcciones multi-moneda bajo un nombre, reduces drásticamente el riesgo de que los clientes envíen fondos a la dirección o cadena incorrecta.

• Presencia de Soporte y Social Auténtica: Publica tus cuentas oficiales de redes sociales en tus registros de texto ENS. Algunas herramientas ya pueden verificar estos registros, creando una defensa fuerte contra la suplantación. Un nombre support.marca.eth puede apuntar directamente a una billetera de soporte dedicada o punto final de mensajería segura.

• Presencia Web Descentralizada: Aloja una página de estado a prueba de manipulaciones o documentación crítica en marca.eth usando el contenthash. Debido a que el enlace está en cadena, no puede ser eliminado por un solo proveedor, ofreciendo un mayor grado de resistencia para información esencial.

• Un Organigrama Programable: Emite subnombres empleado.marca.eth que otorguen acceso a herramientas internas o canales con acceso por tokens. Con fusibles NameWrapper y fechas de expiración, puedes crear un sistema de identidad dinámico, programable y automáticamente revocable para toda tu organización.

• Experiencias de Usuario Ligeras en Gas: Para casos de uso de alto volumen como emitir IDs de lealtad o tickets como subnombres, las transacciones en cadena son demasiado lentas y caras. Usa un resolvedor fuera de cadena con CCIP-Read. Este estándar permite que los nombres ENS se resuelvan desde L2s o incluso bases de datos tradicionales de manera minimizada en confianza. Líderes de la industria como Uniswap (uni.eth) y Coinbase (cb.id) ya usan este patrón para escalar sus sistemas de identidad de usuario.

Seguridad y Gobernanza Que No Deberías Omitir​

Trata tu nombre ENS primario como tratas tu nombre de dominio primario: como una pieza crítica de infraestructura de empresa.

• Separar "Propietario" de "Administrador": Este es un principio de seguridad central. El rol de "Propietario", que tiene el poder de transferir el nombre, debe estar asegurado en una billetera multisig de almacenamiento en frío. El rol de "Administrador", que puede actualizar registros del día a día como direcciones IP o avatares, puede delegarse a una billetera caliente más accesible. Esta separación de poderes reduce drásticamente el radio de explosión de una clave comprometida.

• Usar Protecciones NameWrapper: Al emitir subnombres, usa el NameWrapper para quemar fusibles como CANNOT_TRANSFER para bloquearlos a un empleado específico o CANNOT_UNWRAP para hacer cumplir tus políticas de gobernanza. Todos los permisos están gobernados por una fecha de expiración que controlas, proporcionando acceso limitado en tiempo por defecto.

• Monitorear Renovaciones: No pierdas tu nombre .eth por un pago perdido. Calendariza tus fechas de renovación y recuerda que mientras los nombres .eth tienen un período de gracia de 90 días, las políticas para subnombres dependen completamente de ti.

Inicio Rápido para Desarrolladores (TypeScript)​

Integrar resolución ENS en tu aplicación es simple con librerías modernas como viem. Este fragmento muestra cómo buscar una dirección desde un nombre, o un nombre desde una dirección.

import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";
import { normalize, getEnsAddress, getEnsName, getEnsAvatar } from "viem/ens";

const client = createPublicClient({ chain: mainnet, transport: http() });

export async function lookup(nameOrAddress: string) {
  if (nameOrAddress.endsWith(".eth") || nameOrAddress.includes(".")) {
    // Nombre → Dirección (normalizar entrada según ENSIP-15)
    const name = normalize(nameOrAddress);
    const address = await getEnsAddress(client, {
      name,
      gatewayUrls: ["https://ccip.ens.xyz"],
    });
    const avatar = await getEnsAvatar(client, { name });
    return { type: "name", name, address, avatar };
  } else {
    // Dirección → Nombre Primario (registro inverso)
    const name = await getEnsName(client, {
      address: nameOrAddress as `0x${string}`,
      gatewayUrls: ["https://ccip.ens.xyz"],
    });
    return { type: "address", address: nameOrAddress, name };
  }
}

Dos puntos clave de este código:

• normalize es esencial para seguridad. Hace cumplir las reglas de nomenclatura ENS y ayuda a prevenir ataques comunes de phishing y spoofing de nombres similares.
• gatewayUrls apunta a un Resolvedor Universal que soporta CCIP-Read. Esto hace que tu integración sea compatible hacia adelante con el próximo movimiento a L2 y datos fuera de cadena.

Para desarrolladores construyendo con React, la librería ENSjs ofrece hooks y componentes de nivel superior que envuelven estos flujos comunes, haciendo la integración aún más rápida.

Elegir y Proteger Tu Nombre: Marca y Legal​

• Normalización y Usabilidad: Familiarízate con la normalización ENSIP-15. Establece directrices internas claras sobre el uso de emojis o caracteres no ASCII, y filtra activamente "confundibles" que podrían usarse para suplantar tu marca.
• Verificación de Realidad de Marca Registrada: Los nombres .eth operan fuera del marco tradicional ICANN y su proceso de resolución de disputas UDRP. Los propietarios de marcas registradas no pueden confiar en los mismos rieles legales que usan para dominios DNS. Por lo tanto, el registro defensivo de términos clave de marca es una estrategia prudente. (Esto no es consejo legal; consulta con un abogado.)

Qué Sigue: ENSv2 y el Movimiento a L2​

El protocolo ENS no es estático. La siguiente evolución mayor, ENSv2, está en marcha.

• Protocolo Moviéndose a L2: Para reducir costos de gas y aumentar velocidad, el registro central ENS será migrado a una red de Capa 2. La resolución de nombres será puenteada de vuelta a L1 y otras cadenas a través de CCIP-Read y sistemas de prueba criptográfica. Esto hará que registrar y administrar nombres sea significativamente más barato, desbloqueando patrones de aplicación más ricos.
• Plan de Migración Fluida: El ENS DAO ha publicado un plan de migración detallado para asegurar que los nombres existentes puedan moverse al nuevo sistema con fricción mínima. Si operas a escala, este es un desarrollo clave a seguir.

Lista de Verificación de Implementación​

Usa esta lista de verificación para guiar la implementación de tu equipo.

• Reclamar marca.eth; vincular marca.com a través de DNSSEC sin Gas.
• Estacionar propiedad del nombre en un multisig seguro; delegar roles de administrador.
• Establecer un Nombre Primario en todas las billeteras organizacionales.
• Publicar direcciones multi-moneda para pagos.
• Completar registros de texto (email, url, social, avatar).
• Emitir subnombres para equipos, empleados y servicios usando fusibles y expiración.
• Alojar un sitio descentralizado mínimo (por ejemplo, página de estado) y establecer el contenthash.
• Integrar resolución ENS (viem/ensjs) en tu producto; normalizar todas las entradas.
• Calendarizar todas las fechas de renovación de nombres .eth y monitorear expiración.

ENS está listo para negocios. Se ha movido más allá de un sistema de nomenclatura simple para convertirse en una pieza crítica de infraestructura para cualquier empresa que construya para la próxima generación de internet. Al establecer una identidad programable y persistente, reduces riesgo, creas experiencias de usuario más fluidas y aseguras que tu marca esté lista para un futuro descentralizado.

En 2024, está ocurriendo algo notable: las grandes tecnológicas no solo están explorando blockchain; están desplegando cargas de trabajo críticas en la mainnet de Ethereum. Microsoft procesa más de 100 000 verificaciones de cadena de suministro al día a través de su sistema basado en Ethereum, el piloto de JP Morgan ha liquidado 2,3 mil millones de dólares en transacciones de valores, y la división de blockchain de Ernst & Young ha crecido un 300 % interanual construyendo sobre Ethereum.

Pero la historia más convincente no es solo que estos gigantes estén adoptando blockchains públicas, sino por qué lo hacen ahora y qué nos dice su inversión combinada de 4,2 mil millones de dólares en Web3 sobre el futuro de la tecnología empresarial.

El declive de las blockchains privadas era inevitable (pero no por las razones que piensas)​

La caída de blockchains privadas como Hyperledger y Quorum está ampliamente documentada, pero su fracaso no se debió solo a efectos de red o a ser “bases de datos caras”. Se trató de timing y ROI.

Considera los números: el proyecto medio de blockchain privada empresarial entre 2020‑2022 costó 3,7 millones de dólares de implementación y generó solo 850 000 dólares en ahorros durante tres años (según Gartner). En contraste, los primeros datos de la implementación pública de Ethereum de Microsoft muestran una reducción del 68 % en costos de implementación y ahorros cuatro veces mayores.

Las blockchains privadas eran un anacronismo tecnológico, creadas para resolver problemas que las empresas aún no comprendían del todo. Pretendían des‑riesgar la adopción de blockchain, pero en su lugar generaron sistemas aislados que no podían aportar valor.

Las tres fuerzas ocultas que aceleran la adopción empresarial (y un riesgo importante)​

Aunque la escalabilidad de Layer 2 y la claridad regulatoria se citan a menudo como impulsores, tres fuerzas más profundas están remodelando el panorama:

1. La “AWSificación” de Web3​

Así como AWS abstrajo la complejidad de la infraestructura (reduciendo los tiempos medios de despliegue de 89 días a 3 días), los Layer 2 de Ethereum han convertido blockchain en infraestructura consumible. El sistema de verificación de cadena de suministro de Microsoft pasó de concepto a producción en 45 días sobre Arbitrum, una línea de tiempo que habría sido imposible hace dos años.

Los datos cuentan la historia: los despliegues empresariales en Layer 2 han crecido un 780 % desde enero 2024, con tiempos medios de despliegue que bajaron de 6 meses a 6 semanas.

2. La revolución de los Zero‑Knowledge​

Las pruebas de conocimiento cero no solo resolvieron la privacidad; reinventaron el modelo de confianza. El avance tecnológico se puede medir en términos concretos: el protocolo Nightfall de EY ahora procesa transacciones privadas a una décima parte del costo de soluciones de privacidad anteriores, manteniendo la confidencialidad total de los datos.

Implementaciones empresariales actuales de ZK incluyen:

• Microsoft: verificación de cadena de suministro (100 k tx/día)
• JP Morgan: liquidación de valores (2,3 mil M procesados)
• EY: sistemas de reporte fiscal (250 k entidades)

3. Las cadenas públicas como cobertura estratégica​

El valor estratégico es cuantificable. Las empresas que gastan en infraestructura cloud enfrentan costos medios de lock‑in de proveedores del 22 % de su presupuesto TI total. Construir sobre Ethereum público reduce esto al 3,5 % mientras mantiene los beneficios de los efectos de red.

El contra‑argumento: el riesgo de centralización​

Sin embargo, esta tendencia enfrenta un desafío significativo: el riesgo de centralización. Los datos actuales muestran que el 73 % de las transacciones empresariales en Layer 2 son procesadas por solo tres secuenciadores. Esta concentración podría recrear los mismos problemas de lock‑in que las empresas intentan evitar.

La nueva pila tecnológica empresarial: desglose detallado​

La pila emergente revela una arquitectura sofisticada:

Capa de Liquidación (Ethereum Mainnet):

• Finalidad: bloques de 12 segundos
• Seguridad: 2 mil M de seguridad económica
• Coste: 15‑30 USD por liquidación

Capa de Ejecución (L2s diseñados para propósito):

• Rendimiento: 3 000‑5 000 TPS
• Latencia: 2‑3 segundos de finalización
• Coste: 0,05‑0,15 USD por transacción

Capa de Privacidad (Infraestructura ZK):

• Generación de prueba: 50 ms‑200 ms
• Coste de verificación: 0,50 USD por prueba
• Privacidad de datos: completa

Disponibilidad de datos:

• Ethereum: 0,15 USD por kB
• DA alternativa: 0,001‑0,01 USD por kB
• Soluciones híbridas: crecimiento del 400 % QoQ

Qué sigue: tres predicciones para 2025​

1. Consolidación de Layer 2 empresariales La fragmentación actual (27 L2 enfocadas en empresa) se consolidará en 3‑5 plataformas dominantes, impulsadas por requisitos de seguridad y necesidad de estandarización.

2. Explosión de kits de privacidad Tras el éxito de EY, se esperan más de 50 nuevas soluciones de privacidad empresarial para el cuarto trimestre de 2024. Indicadores tempranos muestran 127 repositorios centrados en privacidad en desarrollo por grandes empresas.

3. Emergencia de estándares cross‑chain Esté atento a que la Enterprise Ethereum Alliance publique protocolos estandarizados de comunicación cross‑chain para el tercer trimestre de 2024, abordando los riesgos de fragmentación actuales.

Por qué esto importa ahora​

La masificación de Web3 marca la evolución de “innovación sin permiso” a “infraestructura sin permiso”. Para las empresas, esto representa una oportunidad de 47 mil millones de dólares para reconstruir sistemas críticos sobre bases abiertas e interoperables.

Métricas de éxito a observar:

• Crecimiento del TVL empresarial: actualmente 6,2 mil M, creciendo un 40 % mensual
• Actividad de desarrollo: más de 4 200 desarrolladores empresariales activos
• Volumen de transacciones cross‑chain: 15 M mensuales, +900 % YTD
• Costes de generación de pruebas ZK: disminuyendo un 12 % mensual

Para los constructores de Web3, no se trata solo de adopción, sino de co‑crear la próxima generación de infraestructura empresarial. Los ganadores serán quienes puedan cerrar la brecha entre la innovación cripto y los requisitos empresariales, manteniendo los valores centrales de la descentralización.

El Valor Extraíble Máximo (MEV) no es solo el coco de los traders—es el motor económico que silenciosamente da forma a cómo se construyen los bloques, cómo las billeteras enrutan órdenes, y cómo los protocolos diseñan mercados. Aquí tienes una guía pragmática para fundadores, ingenieros, traders y validadores.

TL;DR​

• Qué es MEV: Valor extra que un productor de bloques (validador/secuenciador) o sus socios pueden extraer reordenando, insertando o excluyendo transacciones más allá de recompensas base y gas.
• Por qué existe: Mempools públicos, ejecución determinista y dependencias del orden de transacciones (ej. slippage de AMM) crean juegos de ordenamiento rentables.
• Cómo funciona MEV moderno: Una cadena de suministro—billeteras y subastas de flujo de órdenes → searchers → builders → relays → proposers—formalizada por Separación Proposer-Builder (PBS) y MEV-Boost.
• Protecciones de usuario hoy: Envío de transacciones privadas y Subastas de Flujo de Órdenes (OFAs) pueden reducir el riesgo de sandwich y compartir mejoras de precio con usuarios.
• Qué sigue (a septiembre de 2025): PBS consagrado, listas de inclusión, MEV-burn, SUAVE, y secuenciadores compartidos para L2s—todos dirigidos a la equidad y resistencia.

El Modelo Mental de Cinco Minutos​

Piensa en blockspace como un recurso escaso vendido cada 12 segundos en Ethereum. Cuando envías una transacción, aterriza en un área de espera pública llamada mempool. Algunas transacciones, particularmente swaps de DEX, liquidaciones y oportunidades de arbitraje, tienen pagos dependientes del orden. Su resultado y rentabilidad cambian según dónde aterricen en un bloque en relación a otras transacciones. Esto crea un juego de altas apuestas para quien controla el ordenamiento.

La ganancia potencial máxima de este juego es Valor Extraíble Máximo (MEV). Una definición limpia y canónica es:

"El valor máximo extraíble de la producción de bloques en exceso de la recompensa estándar del bloque y tarifas de gas al incluir, excluir y cambiar el orden de las transacciones."

Este fenómeno fue formalizado por primera vez en el paper académico "Flash Boys 2.0" de 2019, que documentó las caóticas "subastas de gas prioritario" (donde los bots subirían las tarifas de gas para que su transacción se incluyera primero) y resaltó los riesgos que esto planteaba para la estabilidad del consenso.

Una Taxonomía Rápida (Con Ejemplos)​

MEV no es una actividad única sino una categoría de estrategias. Aquí están las más comunes:

• Arbitraje DEX (Backrunning): Imagina que un gran swap en Uniswap causa que el precio de ETH caiga en relación a su precio en Curve. Un arbitrajista puede comprar el ETH barato en Uniswap y venderlo en Curve para una ganancia instantánea. Esto es un "backrun" porque sucede inmediatamente después de la transacción que mueve el precio. Esta forma de MEV se considera generalmente beneficiosa ya que ayuda a mantener precios consistentes entre mercados.

• Sandwiching: Esta es la forma más infame y directamente dañina de MEV. Un atacante detecta la orden de compra grande de un usuario en el mempool. Frontrunean al usuario comprando el mismo activo justo antes que ellos, empujando el precio hacia arriba. La operación de la víctima luego se ejecuta a este precio peor y más alto. El atacante luego inmediatamente hace backrun a la víctima vendiendo el activo, capturando la diferencia de precio. Esto explota la tolerancia al slippage especificada del usuario.

• Liquidaciones: En protocolos de préstamos como Aave o Compound, las posiciones se vuelven subcolateralizadas si el valor de su colateral cae. Estos protocolos ofrecen un bono a quien sea el primero en liquidar la posición. Esto crea una carrera entre bots para ser el primero en llamar la función de liquidación y reclamar la recompensa.

• "Guerras de Gas" de Minteo de NFT (Patrón Heredado): En minteos de NFT muy esperados, surge una carrera para asegurar un token de suministro limitado. Los bots competirían ferozmente por los primeros espacios en un bloque, a menudo subiendo los precios de gas a niveles astronómicos para toda la red.

• MEV Cross-Domain: Mientras la actividad se fragmenta entre Layer 1s, Layer 2s y diferentes rollups, surgen oportunidades para beneficiarse de diferencias de precio entre estos entornos aislados. Esta es un área de extracción MEV que crece rápidamente y es compleja.

La Cadena de Suministro MEV Moderna (Post-Merge)​

Antes del Merge, los mineros controlaban el ordenamiento de transacciones. Ahora, los validadores lo hacen. Para prevenir que los validadores se vuelvan demasiado centralizados y especializados, la comunidad Ethereum desarrolló Separación Proposer-Builder (PBS). Este principio separa el trabajo de proponer un bloque para la cadena del trabajo complejo de construir el bloque más rentable.

En la práctica hoy, la mayoría de validadores usan middleware llamado MEV-Boost. Este software les permite subcontratar la construcción de bloques a un mercado competitivo. El flujo de alto nivel se ve así:

1. Usuario/Billetera: Un usuario inicia una transacción, ya sea enviándola al mempool público o a un endpoint RPC privado que ofrece protección.
2. Searchers/Solvers: Estos son actores sofisticados que monitorean constantemente el mempool para oportunidades MEV. Crean "bundles" de transacciones (ej. un frontrun, la operación de la víctima, y un backrun) para capturar este valor.
3. Builders: Estas son entidades altamente especializadas que agregan bundles de searchers y otras transacciones para construir el bloque más rentable posible. Compiten entre sí para crear el bloque de mayor valor.
4. Relays: Estos actúan como intermediarios confiables. Los builders envían sus bloques a relays, que los verifican por validez y ocultan el contenido del proposer hasta que esté firmado. Esto previene que el proposer robe el trabajo duro del builder.
5. Proposer/Validator: El validador ejecutando MEV-Boost consulta múltiples relays y simplemente elige el header de bloque más rentable ofrecido. Lo firman a ciegas, sin ver el contenido, y cobran el pago del builder ganador.

Aunque PBS ha ampliado exitosamente el acceso a la construcción de bloques, también ha llevado a centralización entre un pequeño conjunto de builders y relays de alto rendimiento. Estudios recientes muestran que un puñado de builders produce la gran mayoría de bloques en Ethereum, lo cual es una preocupación continua para la descentralización a largo plazo y resistencia a la censura de la red.

Por Qué MEV Puede Ser Dañino​

• Costo Directo al Usuario: Ataques sandwich y otras formas de frontrunning resultan en peor calidad de ejecución para usuarios. Pagas más por un activo o recibes menos de lo que deberías, con la diferencia siendo capturada por un searcher.
• Riesgo de Consenso: En casos extremos, MEV puede amenazar la estabilidad del blockchain mismo. Antes del Merge, ataques "time-bandit" eran una preocupación teórica donde los mineros podrían ser incentivados a reorganizar el blockchain para capturar una oportunidad MEV pasada, socavando la finalidad.
• Riesgo de Estructura de Mercado: La cadena de suministro MEV puede crear operadores incumbentes poderosos. Acuerdos exclusivos de flujo de órdenes entre billeteras y builders pueden crear paywalls para transacciones de usuario, atrincherando oligopolios de builder/relay y amenazando los principios centrales de neutralidad y resistencia a la censura.

Lo Que Realmente Funciona Hoy (Mitigaciones Prácticas)​

No eres impotente contra MEV dañino. Un conjunto de herramientas y mejores prácticas ha emergido para proteger usuarios y alinear el ecosistema.

Para Usuarios y Traders​

• Usa una Ruta de Envío Privada: Servicios como Flashbots Protect ofrecen un endpoint RPC "protect" para tu billetera. Enviar tu transacción a través de él la mantiene fuera del mempool público, haciéndola invisible a bots sandwich. Algunos servicios pueden incluso reembolsarte una porción del MEV extraído de tu operación.
• Prefiere Routers Respaldados por OFA: Las Subastas de Flujo de Órdenes (OFAs) son una defensa poderosa. En lugar de enviar tu swap al mempool, routers como CoW Swap o UniswapX envían tu intención a un mercado competitivo de solvers. Estos solvers compiten para darte el mejor precio posible, efectivamente devolviendo cualquier MEV potencial a ti como mejora de precio.
• Ajusta el Slippage: Para pares ilíquidos, configura manualmente una tolerancia de slippage baja (ej. 0.1%) para limitar la ganancia máxima que un atacante sandwich puede extraer. Dividir operaciones grandes en trozos más pequeños también puede ayudar.

Para Billeteras y Dapps​

• Integra una OFA: Por defecto, enruta transacciones de usuario a través de una Subasta de Flujo de Órdenes. Esta es la forma más efectiva de proteger usuarios de ataques sandwich y proveerles calidad de ejecución superior.
• Ofrece RPC Privado como Defecto: Haz que RPCs protegidos sean la configuración por defecto en tu billetera o dapp. Permite a usuarios avanzados configurar sus preferencias de builder y relay para ajustar el equilibrio entre privacidad y velocidad de inclusión.
• Mide Calidad de Ejecución: No asumas simplemente que tu enrutamiento es óptimo. Compara tu ejecución contra enrutamiento de mempool público y cuantifica la mejora de precio ganada de OFAs y envío privado.

Para Validadores​

• Ejecuta MEV-Boost: Participa en el mercado PBS para maximizar tus recompensas de staking.
• Diversifica: Conéctate a un conjunto diverso de relays y builders para evitar dependencia de un solo proveedor y mejorar la resistencia de la red. Monitorea tus recompensas y tasas de inclusión de bloques para asegurar que estés bien conectado.

L2s y el Ascenso de SEV (Valor Extraíble por Secuenciador)​

Layer 2 rollups no eliminan MEV; solo cambian su nombre. Los rollups concentran poder de ordenamiento en una sola entidad llamada secuenciador, creando Valor Extraíble por Secuenciador (SEV). La investigación empírica muestra que MEV está extendido en L2s, aunque a menudo con márgenes de ganancia más bajos que en L1.

Para combatir el riesgo de centralización de un solo secuenciador por rollup, están emergiendo conceptos como secuenciadores compartidos. Estos son mercados descentralizados que permiten a múltiples rollups compartir una sola entidad neutral para ordenamiento de transacciones, con el objetivo de arbitrar MEV cross-rollup de manera más justa.

Lo Que Viene Después (Y Por Qué Importa)​

El trabajo para domesticar MEV está lejos de terminar. Varias actualizaciones importantes a nivel de protocolo están en el horizonte:

• PBS Consagrado (ePBS): Esto busca mover la Separación Proposer-Builder directamente al protocolo Ethereum mismo, reduciendo la dependencia de relays centralizados confiables y endureciendo las garantías de seguridad de la red.
• Listas de Inclusión (EIP-7547): Esta propuesta da a los proposers una forma de forzar a un builder a incluir un conjunto específico de transacciones. Es una herramienta poderosa para combatir la censura, asegurando que incluso transacciones con tarifas bajas puedan eventualmente llegar a la cadena.
• MEV-Burn: Similar a cómo EIP-1559 quema una porción de la tarifa base de gas, MEV-burn propone quemar una porción de los pagos de builders. Esto suavizaría picos de ingresos MEV, reduciría incentivos para comportamiento desestabilizador, y redistribuiría valor de vuelta a todos los tenedores de ETH.
• SUAVE (Subasta Única Unificadora para Expresión de Valor): Un proyecto de Flashbots para crear una capa de subasta descentralizada y que preserve la privacidad para flujo de órdenes. El objetivo es crear un mercado más abierto y justo para construcción de bloques y combatir la tendencia hacia acuerdos exclusivos y centralizados.
• Estandarización OFA: Mientras las subastas se vuelven la norma, está en curso el trabajo para crear métricas formales y herramientas abiertas para cuantificar y comparar la mejora de precio ofrecida por diferentes routers, elevando el listón para calidad de ejecución en todo el ecosistema.

Lista de Verificación del Fundador (Envía Productos Conscientes de MEV)​

• Por Defecto a Privacidad: Enruta flujo de usuario a través de sistemas de envío privado o intenciones encriptadas.
• Diseña para Subastas, No Carreras: Evita mecánicas "primero en llegar, primero en ser servido" que crean juegos de latencia. Aprovecha subastas batch o OFAs para crear mercados justos y eficientes.
• Instrumenta Todo: Registra slippage, precio efectivo versus precio del oráculo, y el costo de oportunidad de tus decisiones de enrutamiento. Sé transparente con tus usuarios sobre su calidad de ejecución.
• Diversifica Dependencias: Confía en múltiples builders y relays hoy. Prepara tu infraestructura para la transición a PBS consagrado mañana.
• Planifica para L2s: Si estás construyendo una aplicación multicadena, cuenta con SEV y MEV cross-domain en tu diseño.

FAQ del Desarrollador​

• ¿Es MEV "malo" o "ilegal"? MEV es un subproducto inevitable de mercados blockchain abiertos y deterministas. Algunas formas, como arbitraje y liquidaciones, son esenciales para la eficiencia del mercado. Otras, como sandwiching, son puramente extractivas y dañinas para usuarios. El objetivo no es eliminar MEV sino diseñar mecanismos que minimicen el daño y alineen la extracción con el beneficio del usuario y seguridad de la red. Su estatus legal es complejo y varía por jurisdicción.

• ¿Garantiza el envío de transacciones privadas que no haya sandwiches? Reduce significativamente tu exposición al mantener tu transacción fuera del mempool público donde la mayoría de bots están mirando. Cuando se combina con una OFA, es una defensa muy fuerte. Sin embargo, ningún sistema es perfecto, y las garantías dependen de las políticas específicas del relay privado y builders que uses.

• ¿Por qué no simplemente "apagar MEV"? No puedes. Mientras haya mercados on-chain con ineficiencias de precio (que es siempre), habrá ganancia en corregirlas. Tratar de eliminarlo completamente probablemente rompería funciones económicas útiles. El camino más productivo es gestionarlo y redistribuirlo a través de mejor diseño de mecanismos como ePBS, listas de inclusión, y MEV-burn.

Lectura Adicional​

• Definición canónica y resumen: Docs de Ethereum.org—MEV
• Orígenes y riesgos: Flash Boys 2.0 (Daian et al., 2019)
• Primer de PBS/MEV-Boost: Docs de Flashbots y MEV-Boost in a Nutshell
• Investigación OFA: Uniswap Labs—Quantifying Price Improvement in Order Flow Auctions
• ePBS y MEV-burn: Discusiones del foro Ethereum Research
• Evidencia MEV L2: Análisis empíricos a través de rollups principales (ej. "Analyzing the Extraction of MEV Across Layer-2 Rollups")

Conclusión​

MEV no es un error; es un gradiente de incentivos inherente a blockchains. El enfoque ganador no es la negación—es diseño de mecanismos. El objetivo es hacer la extracción de valor contestable, transparente, y alineada con el usuario. Si estás construyendo, hornea esta conciencia en tu producto desde el día uno. Si estás operando, insiste que tus herramientas lo hagan por ti. El ecosistema está convergiendo rápidamente en este futuro más maduro y resistente—ahora es el momento de diseñar para él.

Ethereum, la plataforma de blockchain más adoptada del mundo para contratos inteligentes, es conocida por sus actualizaciones regulares, cada una de las cuales aporta nuevas funciones, ajustes de parámetros o mayor seguridad. Estas actualizaciones, impulsadas tanto por la innovación proactiva como por la necesidad de mitigar posibles amenazas de seguridad, han marcado la evolución de Ethereum a lo largo de los años.

Antes de la fusión de Ethereum del pasado septiembre, la plataforma había experimentado 14 actualizaciones. Cabe destacar que una actualización reactiva ocurrió en 2016 tras el incidente del Fork DAO, cuando surgió Ethereum Classic (ETC) después de un ciberataque que puso en riesgo los fondos en ETH del proyecto DAO.

En los últimos años se han llevado a cabo actualizaciones significativas. La actualización London, en agosto de 2020, introdujo el EIP‑1599, que implementó la quema de ETH y el ajuste dinámico de la tarifa base para cada transacción. En septiembre de 2022, la actualización Paris cambió el mecanismo de consenso de Ethereum de Prueba de Trabajo (PoW) a Prueba de Participación (PoS), marcando el fin de la era de la minería con máquinas.

Tras la actualización Shanghai, el equipo central de desarrollo de Ethereum anunció que la actualización más importante de este año sería la actualización Cancun, que se espera ocurra a finales de año.

Actualización Cancun: ¿Qué es y por qué importa?​

Nombrada en honor a la ciudad que acogió la Ethereum Developer Conference (Devcon), la próxima actualización Cancun implementará mejoras cruciales en la red Ethereum.

La estrella de la actualización, el EIP‑4844, busca permitir que los nodos de Ethereum almacenen y recuperen temporalmente datos fuera de cadena, satisfaciendo las necesidades de datos y almacenamiento de las aplicaciones blockchain. Si se implementa con éxito, se espera que el EIP‑4844 reduzca los costos de las soluciones de rollup de capa 2 (L2). Según se informa, el EIP‑4844 ya se ha probado en cuatro redes de desarrollo, y una quinta red de pruebas está a punto de lanzarse.

Originalmente previsto para completarse durante la actualización Shanghai, el EIP‑4844 se pospuso a la actualización Cancun. Los desarrolladores también acordaron incluir el EIP‑6780 (preparación para la futura aplicación de Árboles Verkle), el EIP‑6475 (mejora de la legibilidad y serialización compacta) y el EIP‑1153 (introducción del opcode de almacenamiento transitorio) en la actualización.

El principio detrás de la actualización​

La esencia de los esfuerzos de escalabilidad de Ethereum radica en aumentar el volumen y la velocidad de procesamiento de datos. Se persiguen simultáneamente dos direcciones: rollups de capa 2 y sharding en la mainnet. La implementación del EIP‑4844 es el primer paso hacia un sharding completo.

Antes de la actualización Cancun, la información de L2 se almacenaba en el Calldata de la información de L1. Este método resultaba costoso y limitado debido al espacio restringido del Calldata.

Con la actualización Cancun, L1 se almacenará en una nueva ubicación llamada “Blob”. El almacenamiento de blobs es más económico y ofrece mayor capacidad, permitiendo que Ethereum aloje más datos, aumente sus transacciones por segundo (TPS) y reduzca costos. Como el Blob es un paquete de datos temporal que se elimina cada 30 días, los nodos solo necesitan descargar una cantidad fija de datos al mes, disminuyendo la carga sobre ellos.

En esencia, la actualización Cancun hará que L2 sea más barata y rápida. Esto no solo beneficiará a los protocolos de L2, sino que también fomentará un desarrollo rápido de los ecosistemas construidos sobre L2.

En conclusión, la próxima actualización Cancun de Ethereum promete ser un hito importante, anunciando una nueva era de aplicaciones blockchain eficientes, asequibles y escalables. Mantente atento a futuras actualizaciones mientras la comunidad de Ethereum continúa su trabajo pionero en el avance de tecnologías descentralizadas.

¡Hola y bienvenidos de nuevo a nuestro blog de blockchain! Hoy nos sumergiremos en una nueva propuesta emocionante llamada ERC-4337, que introduce la abstracción de cuentas en Ethereum sin requerir cambios en el protocolo de la capa de consenso. En su lugar, esta propuesta se basa en infraestructura de capa superior para lograr sus objetivos. Exploremos lo que ERC-4337 tiene para ofrecer y cómo aborda las limitaciones del ecosistema actual de Ethereum.

¿Qué es ERC-4337?​

ERC-4337 es una propuesta que introduce la abstracción de cuentas en Ethereum mediante el uso de un mempool separado y un nuevo tipo de objeto pseudo‑transacción llamado UserOperation. Los usuarios envían objetos UserOperation al mempool alternativo, donde una clase especial de actores llamados bundlers los empaquetan en una transacción que realiza una llamada handleOps a un contrato dedicado. Estas transacciones se incluyen luego en un bloque.

La propuesta busca lograr varios objetivos:

1. Permitir a los usuarios utilizar carteras de contratos inteligentes con lógica de verificación arbitraria como sus cuentas principales.
2. Eliminar por completo la necesidad de que los usuarios tengan cuentas externas (EOAs).
3. Garantizar la descentralización permitiendo que cualquier bundler participe en el proceso de inclusión de operaciones de usuario con abstracción de cuentas.
4. Permitir que toda la actividad ocurra a través de un mempool público, eliminando la necesidad de que los usuarios conozcan direcciones de comunicación directa de actores específicos.
5. Evitar suposiciones de confianza sobre los bundlers.
6. Evitar requerir cambios en el consenso de Ethereum para una adopción más rápida.
7. Soportar otros casos de uso como aplicaciones que preservan la privacidad, multi‑operaciones atómicas, pagar tarifas de transacción con tokens ERC‑20 y transacciones patrocinadas por desarrolladores.

Compatibilidad hacia atrás​

Dado que ERC-4337 no modifica la capa de consenso, no existen problemas directos de compatibilidad hacia atrás para Ethereum. Sin embargo, las cuentas anteriores a ERC-4337 no son fácilmente compatibles con el nuevo sistema porque carecen de la función validateUserOp necesaria. Esto puede solucionarse creando una cuenta compatible con ERC-4337 que re‑implemente la lógica de verificación como un wrapper y configurándola como el remitente de operaciones de confianza de la cuenta original.

Implementación de referencia​

Para quienes estén interesados en profundizar en los detalles técnicos de ERC-4337, hay una implementación de referencia disponible en https://github.com/eth-infinitism/account-abstraction/tree/main/contracts.

Consideraciones de seguridad​

El contrato de punto de entrada para ERC-4337 debe ser auditado exhaustivamente y verificado formalmente, ya que sirve como punto central de confianza para todo el sistema. Si bien este enfoque reduce la carga de auditoría y verificación formal para cuentas individuales, concentra el riesgo de seguridad en el contrato de punto de entrada, que debe ser verificado de manera robusta.

La verificación debe cubrir dos afirmaciones principales:

1. Seguridad contra secuestros arbitrarios: el punto de entrada solo llama a una cuenta de forma genérica si la función validateUserOp de esa cuenta específica ha pasado.
2. Seguridad contra el drenaje de tarifas: si el punto de entrada llama a validateUserOp y pasa, también debe realizar la llamada genérica con calldata igual a op.calldata.

Conclusión​

ERC-4337 es una propuesta emocionante que busca introducir la abstracción de cuentas en Ethereum sin requerir cambios en el protocolo de la capa de consenso. Al utilizar infraestructura de capa superior, abre nuevas posibilidades para la descentralización, la flexibilidad y diversos casos de uso. Aunque existen consideraciones de seguridad que abordar, esta propuesta tiene el potencial de mejorar significativamente el ecosistema de Ethereum y la experiencia del usuario.

Retiros, ajustes de gas, y lo que vino después—sin la propaganda.

La Versión Corta​

La actualización Shapella, un acrónimo de Shanghai (para la capa de ejecución) y Capella (para la capa de consenso), se activó en Ethereum el 12 de abril de 2023. Su característica principal fue habilitar los retiros de staking por primera vez desde el lanzamiento de la Beacon Chain.

El cambio más destacado, EIP-4895, introdujo un sistema donde los retiros de validadores se "empujan" automáticamente desde la capa de consenso a la capa de ejecución, sin requerir transacciones de usuario ni tarifas de gas. Junto a esto, se implementaron cuatro EIPs menores para ajustar la EVM, incluyendo reducciones en el costo del gas (Warm COINBASE), optimizaciones de bytecode (PUSH0), y límites en la creación de contratos (Initcode metering). La actualización también sirvió como advertencia final a los desarrolladores de que el opcode SELFDESTRUCT estaba siendo descontinuado.

Shapella cerró efectivamente el ciclo del Merge, y la siguiente actualización mayor, Dencun, llegó el 13 de marzo de 2024, cambiando el foco de la red hacia la escalabilidad con los "blobs" de EIP-4844.

Por Qué Shapella Fue un Hito Crítico​

Desde el inicio de la Beacon Chain hasta abril de 2023, hacer staking con ETH era una calle de un solo sentido. Podías depositar 32 ETH para ayudar a asegurar la red y ganar recompensas, pero no podías retirar tu capital principal o esas recompensas de la capa de consenso. Esta liquidez bloqueada representaba un compromiso significativo y una barrera para muchos stakers potenciales.

Shapella cambió todo al abrir la puerta de salida.

El núcleo de la actualización fue EIP-4895, que diseñó ingeniosamente una "operación de retiro" a nivel de sistema. En lugar de requerir que los stakers elaboren una transacción y paguen gas para retirar, el protocolo mismo ahora automáticamente recoge fondos elegibles de la capa de consenso y los empuja a la capa de ejecución. Este diseño limpio, basado en empuje, minimizó la complejidad y el riesgo, haciendo mucho más fácil probar e implementar el cambio de manera segura.

Lo Que Realmente Cambió: Los EIPs en Español Simple​

Shapella fue un paquete de cinco Propuestas de Mejora de Ethereum (EIPs) clave:

• EIP-4895 — Retiros de Beacon Chain (Basados en Empuje) Este fue el evento principal. Habilitó tanto retiros parciales (recompensas) como completos (principal + recompensas) para fluir desde la capa de consenso a la dirección de retiro especificada del staker. La innovación clave es que estas no son transacciones iniciadas por usuario; son operaciones automáticas embebidas en bloques propuestos.

• EIP-3651 — "Warm COINBASE" Este EIP hizo una optimización de gas pequeña pero importante. En la EVM, COINBASE se refiere a la dirección del productor del bloque (el validador), no el exchange. Antes de Shapella, la primera vez que un contrato inteligente accedía a esta dirección dentro de una transacción, incurría en un costo de gas más alto. EIP-3651 hizo que la dirección COINBASE fuera "warm" por defecto, reduciendo el costo de gas para protocolos que interactúan frecuentemente con ella, como aquellos que pagan propinas MEV directamente al constructor de bloques.

• EIP-3855 — Opcode PUSH0 Una adición simple pero elegante a la EVM. Este nuevo opcode, PUSH0, hace exactamente lo que dice: empuja el valor cero al stack. Anteriormente, los desarrolladores tenían que usar opcodes más pesados y costosos para lograr esto. PUSH0 hace el bytecode ligeramente más pequeño y eficiente en gas, especialmente para los numerosos contratos que inicializan variables en cero.

• EIP-3860 — Limitar y Medir initcode Este cambio introdujo dos reglas para el código usado para crear un contrato inteligente (initcode). Primero, estableció un límite máximo en el tamaño del initcode de 49,152 bytes. Segundo, agregó una pequeña tarifa de gas por cada chunk de 32 bytes de este código. Esto previene ataques de denegación de servicio que involucran contratos excesivamente grandes y hace los costos de creación de contratos más predecibles.

• EIP-6049 — Deprecar SELFDESTRUCT (Advertencia) Esto no fue un cambio de código sino una advertencia formal a la comunidad de desarrolladores. Señaló que el opcode SELFDESTRUCT, que permite a un contrato eliminarse a sí mismo y enviar su ETH a una dirección objetivo, tendría su funcionalidad drásticamente cambiada en una actualización futura. Esto dio tiempo a los desarrolladores para eliminar gradualmente su dependencia de él antes de que la actualización Dencun alterara posteriormente su comportamiento con EIP-6780.

Retiros 101: Parciales vs. Completos​

Shapella introdujo dos tipos de retiros automáticos, cada uno con sus propias reglas.

• Retiros Parciales Estos son barridos automáticos de recompensas. Si el balance de un validador crece por encima de 32 ETH debido a recompensas de la capa de consenso, el protocolo automáticamente "descremó" la cantidad excedente y la envía a la dirección de retiro designada. El validador permanece activo y continúa sus deberes. Esto sucede sin acción requerida del staker.

• Retiros Completos (Salida) Esto es para stakers que quieren dejar de validar y recuperar todo su balance. El staker debe primero transmitir un mensaje de salida voluntaria. Después de un período de espera, el validador se vuelve elegible para un retiro completo. Una vez procesado en el barrido, todo el balance se envía a la dirección de retiro, y el validador ya no es parte del conjunto activo.

Rendimiento y Cadencia​

La red está diseñada para procesar retiros suavemente sin causar inestabilidad.

• Hasta 16 retiros pueden incluirse en cada bloque (cada 12 segundos), permitiendo un máximo de aproximadamente 115,200 retiros por día.
• El proponente del bloque escanea la lista de validadores activos e incluye los primeros 16 retiros elegibles. El siguiente proponente de bloque continúa donde el último se quedó, asegurando que cada validador obtenga su turno en la cola.
• Para prevenir un éxodo masivo de desestabilizar la red, el número de validadores que pueden salir por época (cada ~6.4 minutos) está limitado por un límite de rotación. Este límite es dinámico basado en el número total de validadores activos, suavizando las olas de salida.

También es importante notar que las recompensas de la capa de consenso son manejadas por este mecanismo de retiro EIP-4895, mientras que las recompensas de la capa de ejecución (tarifas prioritarias y MEV) se envían directamente a la dirección de destinatario de tarifas configurada del validador y están disponibles inmediatamente.

Lo Que Vino Después: Dencun y el Camino a la Escalabilidad​

Shapella marcó la exitosa finalización de la "era del Merge." Con staking ahora siendo un proceso completamente líquido y bidireccional, los desarrolladores dirigieron su atención al siguiente gran desafío de Ethereum: escalabilidad.

La siguiente actualización mayor, Dencun (Deneb + Cancun), llegó el 13 de marzo de 2024. Su pieza central fue EIP-4844, que introdujo "blobs"—una nueva forma más barata para rollups de Capa 2 de publicar datos de transacciones a la mainnet de Ethereum. Esto redujo dramáticamente las tarifas de transacciones en L2s y fue un paso masivo hacia adelante en la hoja de ruta centrada en rollups. Dencun también cumplió la promesa de EIP-6049 al implementar EIP-6780, que redujo significativamente el poder del opcode SELFDESTRUCT.

El Panorama General​

Shapella fue el hito de confianza esencial para el consenso Proof-of-Stake de Ethereum. Al habilitar retiros, des-arriesgó el staking, restauró la liquidez, y afirmó la capacidad de la red para ejecutar actualizaciones complejas y coordinadas. También entregó un puñado de mejoras pragmáticas de EVM que limpiaron deuda técnica y pavimentaron el camino para optimizaciones futuras.

En resumen, Shapella no solo abrió la puerta de salida para los stakers—solidificó la base de la era post-Merge y despejó la pista para que Ethereum se enfocara en su siguiente frontera: escalabilidad masiva.