Recientemente, ha habido una tendencia notable donde un número creciente de dApps están anunciando el lanzamiento de sus propios rollups. Además, hay un aumento en el número de rollups genéricos que están listos para salir al mercado.

Los rollups genéricos abordan los problemas de escalabilidad de Ethereum a medida que enfrenta volúmenes de transacciones crecientes y el crecimiento de dApp. Estas soluciones de capa 2 procesan más transacciones fuera de la cadena, para luego asegurarlas en la cadena principal, equilibrando la escalabilidad con la seguridad. Su versatilidad soporta varias dApps, eliminando la necesidad de soluciones de escalado únicas para cada aplicación.

Los rollups específicos de aplicaciones son soluciones a medida que abordan las necesidades únicas de aplicaciones individuales. Ofrecen una velocidad mejorada al optimizar el procesamiento de transacciones para casos de uso específicos. En cuanto a costos, podrían proporcionar una alternativa más eficiente a soluciones genéricas, especialmente durante la congestión de la red. Su característica destacada es la flexibilidad. A diferencia de las soluciones de capa 2 de propósito general que son rígidas y están más limitadas por el diseño enraizado de EVM, los rollups específicos de aplicaciones pueden ser personalizados, lo que los hace ideales para aplicaciones como juegos que requieren precompilaciones específicas. Además, permiten a las dApps capturar mejor el valor, ofreciendo más control sobre la economía de tokens y las corrientes de ingresos.

Con el consenso formándose en torno a la proliferación de rollups, mirando un año hacia el futuro donde múltiples rollups dominan el mercado, la necesidad de una infraestructura robusta se vuelve primordial. Esta infraestructura servirá como el “hormigón armado” de un mundo multi-rollup.

Este artículo profundizará en cuatro pilares fundamentales que darán forma al futuro del ecosistema multi-rollup:

1. Seguridad como base: La capa de seguridad es la base de confianza en el mundo descentralizado. En esta sección, exploramos el papel vital que desempeña en garantizar la integridad de las transacciones de Capa 2, identificando suposiciones de confianza y abordando posibles obstáculos de seguridad.
2. Equilibrando la personalización y la interoperabilidad: Lograr una interoperabilidad perfecta entre diversos rollups es fundamental para un mundo de blockchain modular. En esta sección, analizamos los problemas de interoperabilidad que trae consigo una estructura modular y discutimos las soluciones actuales para abordar la fragmentación y fomentar un ecosistema cohesivo.
3. Análisis de costos: Reducir los costos es crucial para la adopción más amplia y la viabilidad de los rollups, ya que reduce las barreras económicas en comparación con la utilización de contratos inteligentes. La eficiencia de costos en los rollups se logra principalmente mediante la explotación de economías de escala al agregar con otros rollups para compartir tarifas y al adoptar la división del trabajo al delegar ciertas tareas a proveedores de servicios externos.
4. Seguridad compartida: una capa de seguridad compartida es esencial, ya que alivia el proceso intensivo en tiempo y recursos de iniciar la seguridad para nuevos protocolos o capas modulares, asegurando una seguridad robusta comparable a plataformas establecidas como Ethereum. Han surgido numerosas soluciones como Eigenlayer, Babilonia, ICS de Cosmos y Seguridad de Malla, que muestran una variedad de aplicaciones

Juntas, estas cuatro capas proporcionarán un plan integral para la infraestructura necesaria para apoyar un mundo blockchain modular próspero y cohesivo.

Seguridad como base

En el corazón de cualquier sistema descentralizado yace la confianza y la seguridad. Su ausencia socava la promesa misma de un ecosistema sin confianza. Por eso, la capa de seguridad es primordial; sin ella, los usuarios y TVL están en riesgo. La caída de Plasma y las Sidechains ofrece una historia de advertencia. Una vez visto como el salvador de escalabilidad de Ethereum, sus problemas, como el "problema de disponibilidad de datos," socavaron la confianza y llevaron a su popularidad decreciente. Por eso, la capa de seguridad se convierte en parte I de este artículo.

Para entender las complejidades de los rollups y sus posibles vulnerabilidades, es esencial diseccionar el ciclo de vida de una transacción de Capa 2. Utilizando los rollups de contratos inteligentes como referencia, adentrémonos en cada fase e identifiquemos las suposiciones de confianza y posibles problemas de seguridad.

1. Tx Submission through RPC:
   1. Suposición de confianza: El punto final de RPC es confiable y seguro. Los usuarios y las dapps ahora confían en los proveedores de rpc, por ejemplo, alquimia, infura, etc.
   2. Preocupación de seguridad: Los usuarios podrían ser censurados por proveedores de rpc, por ejemplo, infura y alchemy bloqueando solicitudes de rpc a Gate.ioefectivo de tornado. Los proveedores de RPC podrían enfrentarse a ataques DDOS, por ejemplo, ankr siendo comprometido a través de Secuestro de DNS.
   3. Soluciones: Los proveedores de RPC, como Infura, están persiguiendo activamente una hoja de ruta descentralizada. Además, los usuarios tienen la opción de elegir soluciones descentralizadas como Pocket Network.
2. Sequenciador Ordena la Tx, Proporciona Compromisos Suaves: estado inseguro
   1. Suposición de confianza: Los usuarios esperan que los secuenciadores ordenen las transacciones de forma justa y proporcionen compromisos suaves genuinos.
   2. Preocupación por la seguridad: El sistema debe resistir la censura, asegurando que todas las transacciones se procesen sin sesgo. Es crucial que el sistema permanezca operativo de forma continua, y sería mejor protegerse contra los secuenciadores que obtienen mal MEV a expensas del usuario final.
   3. Soluciones:
      1. CR y vivacidad:
         1. clasificación actual de soluciones basada en CR y nivel de viabilidad (de bajo a alto): secuenciador único——POA——secuenciadores POS permisionados——secuenciadores compartidos——rollups basados en l1 (secuenciados por l1)
            1. Tenga en cuenta que POA con autoridades limitadas sin soporte para transacciones forzadas puede tener menos CR que un secuenciador centralizado con transacciones forzadas habilitadas.
            2. Con respecto a la vitalidad, otra métrica crucial a considerar es el fallo del proponente, que ocurre cuando un proponente se desconecta. En tales casos, es esencial asegurar que los usuarios aún puedan retirar sus fondos.
               1. Incluso si los secuenciadores están censurando o se niegan a funcionar, algunos rollups permiten a los usuarios enviar sus txs directamente a L1s por sí mismos, es decir, la salida de emergencia (la vivacidad de las txs forzadas depende de la implementación específica). El problema es que podría ser demasiado caro para los usuarios con fondos limitados hacerlo y los usuarios podrían esperar CR en tiempo real y vivacidad.
               2. Ciertas soluciones de rollup, como Arbitrum y Fuel, ofrecen la capacidad para que cualquier persona se convierta en proponente después de un cierto retraso en el tiempo, es decir, autopropuesto.
               3. Echa un vistazo a este indicador para cada rollup: https://l2beat.com/scaling/risk
         2. Más detalles sobre otras soluciones diferentes se pueden consultar en mi hilo anterior: https://twitter.com/yuxiao_deng/status/1666086091336880128
      2. Protección MEV:
         1. Diferentes soluciones de privacidad pueden ayudar a proteger a los usuarios de ser front-run o sandwiched ya que la información de la tx está oculta (también ayuda con CR). Los métodos relacionados para ocultar la información de la tx incluyen FCFS con un mempool privado (lo que arbitrum y optimism están implementando en este momento), la solución TEE de SUAVE, el cifrado de umbral (shutter network está trabajando en esto), etc. Cuanto más sofisticada sea la solución, menos complicados pueden ser los cálculos en las txs.

MEV Roast | Piscinas de Memorias Encriptadas - Justin Drake (Fundación Ethereum) - YouTube

1. Ten en cuenta que lo que queremos es protección de MEV, no eliminación de MEV.Investigación por @tarunchitraresume dos direcciones principales para reducir MEV: reducir la flexibilidad del minero para reordenar transacciones mediante la imposición de reglas de ordenamiento e introducir un mercado competitivo para el derecho de reordenar, agregar y/o censurar transacciones. Sin embargo, el artículo concluye que ni el ordenamiento justo ni los mecanismos económicos por sí solos pueden mitigar efectivamente MEV para todas las funciones de pago. Hay límites inferiores sobre cómo no se puede eliminar MEV más allá de cierto punto.
2. El secuenciador ejecuta y publica lotes de transacciones y raíces de estado en la capa DA cuando es económicamente razonable; estado seguro
   1. Suposición de confianza: los productores de bloques publican todo el bloque en la capa DA para que otros puedan descargarlos y validarlos.
   2. Preocupación de seguridad: Si parte de los datos no está disponible, el bloque podría contener transacciones maliciosas que están siendo ocultadas por el productor de bloques. Incluso si el bloque contiene transacciones no maliciosas, ocultarlas podría comprometer la seguridad del sistema. Es muy importante que los secuenciadores tengan datos de tx disponibles, ya que el rollup necesita conocer el estado de la red y los saldos de cuentas.
   3. Soluciones:
   4. Publicar en Ethereum ahora es la solución más segura pero más cara (sería un 90% más barata después de la compartición de protodank, pero incluso un aumento de 10 veces en el rendimiento aún podría no ser suficiente para los rollups): las transacciones de los rollups son descargadas y difundidas por todos los nodos de Ethereum. Dado que Ethereum tiene una gran cantidad de nodos que replican y verifican los datos de transacciones, es muy poco probable que los datos desaparezcan o estén completamente no disponibles.
      1. Después de danksharding, los nodos de ethereum no descargarán todos los datos de tx, sino solo partes de los datos utilizando DAS y KZG (similar a la solución de avail mencionada a continuación)
      2. Bajo el concepto modular, podría ser más eficiente para los rollups publicar datos de tx en una capa DA que solo sea responsable de DA (El rendimiento teórico de Ethereum podría ser ligeramente inferior porque, además de DA, aún conserva la ejecución de L1, consulte la comparación de rendimiento entre eigenDA y Ethereum a continuación).

1. Las soluciones DA modulares actuales presentan compensaciones entre seguridad y rendimiento. Es un desafío comparar la seguridad de DA utilizando solo una dimensión:
   1. Avail y Celestia utilizan DAS para garantizar la disponibilidad de los datos; siempre que haya suficiente muestreo, los datos están asegurados. Los CL pueden muestrear y obtener una alta garantía de DA, ya que la falta de disponibilidad de datos sería fácilmente detectada y recuperada por porciones muy pequeñas de CL. Esto no sería posible sin DAS. La descentralización de la capa DA, es decir, el número de nodos en la red, determina el nivel de seguridad y también la distribución de participaciones. EigenDA no utiliza DAS, pero utiliza un mecanismo de prueba de custodia para evitar que los reestacadores sean perezosos, es decir, los operadores de DA deben calcular rutinariamente una función que solo se puede completar si han descargado todos los datos requeridos y son penalizados si no atestiguan los blobs correctamente (aunque no es necesario almacenarlos después de que se haya realizado la prueba).
   2. Asegúrese de que el proceso de duplicación de datos, es decir, la codificación de borrado, sea preciso. EigenDA, Ethereum después de 4844, y Avail utilizan compromisos kzg para garantizar la precisión, pero estos son computacionalmente intensivos. Celestia emplea pruebas de fraude. Los nodos ligeros deben esperar un intervalo breve antes de poder confirmar que un bloque ha sido codificado correctamente, finalizándolo desde su perspectiva. (*Celestia podría potencialmente cambiar a pruebas de validez si es una opción de intercambio mejor)
   3. Seguridad económica de la capa DA (riesgos de reorganización y colusión): depende del valor apostado en la capa DA, =2/3 del valor apostado en Avail y Celestia
   4. Transmitir la acreditación DA de la capa DA a Ethereum. Si los datos se publican en otra capa DA mientras el contrato de liquidación todavía está en Ethereum, entonces necesitamos un contrato puente para validar que la DA está disponible en la capa DA para la liquidación final.
      1. La blobstream de Celestia verifica las firmas en la certificación DA de Celestia. La certificación es una raíz de Merkle de los datos L2 firmada por los validadores de Celestia que atestiguan el hecho de que los datos están disponibles en Celestia. Esta función está disponible en testnetahora mismo.
      2. Avail utiliza un enfoque optimista para verificar la certificación DA. Una vez que la certificación se publica en el contrato del puente en Ethereum, comienza un período de espera durante el cual se supone que la certificación es válida a menos que se cuestione.
      3. Succinct está trabajando con Avail y Celestia en un puente de certificación de datos basado en zk-SNARK, lo que hace que el progreso de la certificación sea más seguro y más barato al solo verificar la prueba zk.
      4. Para EigenDA, el dispersor divide y publica tareas a los nodos de EigenDA y luego reúne firmas de ellos y transmite datos a Ethereum
2. Liquidación final: estado finalizado
   1. Suposición de confianza 1:
      1. Los nodos completos de Rollup (un nodo que puede calcular completamente el estado sin depender de otras pruebas) pueden finalizar el primer bloque de Rollup válido en su altura tan pronto como se publique en la cadena principal, ya que tienen los datos necesarios y los recursos computacionales para verificar rápidamente la validez del bloque. Sin embargo, esto no es el caso para otras terceras partes como los clientes livianos, que dependen de pruebas de validez, pruebas de fraude o protocolos de resolución de disputas para verificar el estado de manera confiable sin necesidad de ejecutar una réplica completa de la cadena ellos mismos.
   2. Preocupación de seguridad 1:
      1. Para ZK Rollups, l1 verifica el zkp y solo acepta raíces de estado correctas. La dificultad radica principalmente en el costo y el proceso de generación de zkp.
      2. Por otro lado, los Rollups Optimistas dependen de la premisa de que al menos una parte honesta presentará pruebas de fraude de manera oportuna para impugnar cualquier transacción maliciosa. Sin embargo, la mayoría de los sistemas actuales de prueba de fraude aún no son sin permiso, y la presentación de pruebas de fraude depende solo de algunos validadores.
   3. Soluciones 1:
      1. Permiso para probar fraudes sin permiso habilitado por el protocolo BOLD de Arbitrum. La razón principal por la que la prueba de fraudes está permitida en este momento es la preocupación por los ataques de retraso:
         1. Durante el período de desafío, cualquier apostador que no sea el proponente puede lanzar un desafío. Luego, el proponente debe defender su afirmación contra cada retador individualmente, uno a la vez. Al final de cada desafío, la parte perdedora pierde su apuesta.
         2. En un ataque de retraso, una parte maliciosa (o grupo de partes) puede evitar o retrasar la confirmación de los resultados de vuelta a la cadena L1 haciendo desafíos y perdiendo deliberadamente la disputa y las apuestas)
         3. El protocolo de desafío 𝐁𝐎𝐋𝐃 aborda esto garantizando límites superiores fijos en los tiempos de confirmación para el establecimiento de Optimistic Rollups al asegurar que una sola parte honesta en el mundo pueda ganar contra cualquier cantidad de reclamaciones maliciosas.
      2. La cadena de testigos puede actuar como una torre de vigilancia para nuevos rollups optimistas para garantizar que al menos una parte honesta desafiaría un estado inválido:
         1. Para rollups establecidos como Arbitrum y Optimism, existen suficientes incentivos intrínsecos para varios proveedores de terceros como exploradores, servicios similares a Infura y su fundación para monitorear el estado de la cadena y enviar pruebas de fraude cuando sea necesario. Sin embargo, los nuevos rollups o appchains podrían carecer de este nivel de seguridad.
         2. Witness Chain emplea un mecanismo de incentivos único, la "Prueba de Diligencia", que garantiza que las torres de vigilancia (validadores) estén constantemente motivadas para monitorear y verificar las transacciones, asegurando que el estado enviado a la cadena principal sea correcto. Este mecanismo garantiza que cada atalaya realice su debida diligencia ya que las recompensas que reciben son específicas e independientes para cada nodo. En otras palabras, si una atalaya descubre una recompensa, no puede compartir el pago exacto del incentivo con otras atalayas, asegurando que cada nodo lleve a cabo su verificación independiente. Además, Witness Chain ofrece flexibilidad al permitir que los rollups especifiquen requisitos personalizados, como el número de torres de vigilancia y su distribución geográfica impulsada por la "prueba de ubicación", su servicio independiente. Esta flexibilidad garantiza un equilibrio entre seguridad y eficiencia. \
            La red de Watchtower también está emergiendo como una nueva capa en la pila de rollup en sí misma, proporcionando seguridad agrupada a la ejecución utilizada por otras aplicaciones relacionadas, como la propia seguridad de rollup, protocolos de interoperabilidad, servicio de notificación y red de guardianes, etc. Más detalles se lanzarán en el futuro.
   4. Suposición de confianza 2:
      1. Todo el proceso de liquidación para rollups de contratos inteligentes está escrito en contrato inteligente en L1. Se asume que el contrato inteligente en la capa DA es lógicamente preciso, libre de errores y no se actualiza malévolamente.
   5. Preocupación de seguridad 2: Los puentes y actualizaciones de rollups de contratos inteligentes están controlados por billeteras multi-sig. El puente tiene la capacidad de robar fondos arbitrariamente a los usuarios a través de una actualización maliciosa.
   6. Soluciones 2:
      1. La idea más popular hoy en día es agregar retrasos temporales que permitan a los usuarios salir si no están de acuerdo con una actualización planificada. Sin embargo, esta solución requiere que los usuarios monitoreen continuamente todas las cadenas en las que tienen tokens en caso de que necesiten salir en algún momento.
      2. La Capa Beacon de Altlayer puede actuar como una capa social para las actualizaciones de todos los rollups consagrados a ella. Los secuenciadores que se registran para operar un rollup junto con los validadores de rollup de la Capa Beacon pueden bifurcar socialmente el rollup independientemente de si se actualiza o no el contrato de puente consagrado en Ethereum.
      3. Rollups consagrados a largo plazo: el rollup consagrado ha sido el objetivo final del mapa de ruta de Ethereum durante varios años. Excepto por el puente verificador de pruebas de fraude consagrado en L1, el contrato de liquidación también está consagrado.
         1. Ethereum PSE está trabajando en esta dirección

En cuanto a los rollups soberanos, la principal diferencia es que el estado de la cadena se establece mediante los nodos completos de rollup en lugar del contrato inteligente consagrado en el L1. Se puede hacer referencia a una comparación más detallada.https://www.cryptofrens.info/p/settlement-layers-ethereum-rollups

Es importante tener en cuenta que una mayor seguridad no equivale a un mejor rendimiento. Por lo general, a medida que aumentan las medidas de seguridad, hay un compromiso con la escalabilidad. Por lo tanto, es esencial encontrar un equilibrio entre los dos. En conclusión, los rollups ofrecen la flexibilidad para seleccionar diferentes niveles de suposiciones de seguridad según las preferencias individuales. Esta adaptabilidad es una de las características notables del mundo modular, que permite un enfoque personalizado para satisfacer necesidades específicas manteniendo la integridad del sistema.

Equilibrando la personalización y la interoperabilidad

Es un adagio bien conocido en el mundo modular: "Modularismo, no maximalismo." Si los rollups no pueden interoperar de forma segura y eficiente, entonces el modularismo ≠ maximalismo sino = fragmentación. Es crucial averiguar cómo manejar la interoperabilidad entre diferentes rollups.

Primero, volvamos a revisar cómo las cadenas monolíticas logran la interoperabilidad. En términos más simples, logran operaciones entre cadenas verificando el consenso o estado de la otra cadena. Hay varios enfoques disponibles en el mercado, y las diferencias radican en quién es responsable de la verificación (entidades oficiales, mecanismos de multi-firma, redes descentralizadas, etc.) y cómo se garantiza la corrección de la verificación (a través de partes externas, garantías económicas, mecanismos optimistas, pruebas zk, etc.). Para profundizar en este tema, echa un vistazo a mis piezas de conexión favoritas:Pensamientos sobre Interoperabilidad.

Con el auge de la modularización, el problema de la interoperabilidad se ha vuelto más intrincado:

1. Problema de fragmentación:
   1. Se espera que la proliferación de rollups supere significativamente el número de L1, ya que es mucho más fácil aterrizar en un l2 que en l1. ¿Podría esto llevar a una red altamente fragmentada?
   2. Si bien las cadenas de bloques monolíticas ofrecen un consenso y estado consistentes para una verificación sencilla, ¿cuál será el proceso de verificación para las cadenas de bloques modulares que tienen tres (o posiblemente cuatro) componentes distintos (DA, ejecución, liquidación y secuenciación)?
      1. DA y la capa de liquidación se convierten en la principal fuente de verdad. La verificación de la ejecución ya está disponible, ya que los rollups proporcionan inherentemente pruebas de ejecución. La secuenciación ocurre antes de publicar en DA.
2. Problema extensible:
   1. A medida que se introducen nuevos rollups, surge la pregunta: ¿podemos ofrecer rápidamente servicios de puente para acomodarlos? Incluso si la construcción de un rollup es sin permiso, es posible que necesites pasar 10 semanas convenciendo a otras personas para agregar uno. Los servicios de puente actuales atienden predominantemente a los rollups y tokens principales. Con la posible afluencia de numerosos rollups, existe la preocupación sobre si estos servicios pueden evaluar y lanzar de manera eficiente soluciones correspondientes para apoyar estos rollups emergentes sin comprometer la seguridad y funcionalidad.
3. Problema de experiencia de usuario:
   1. El ajuste final de los rollups optimistas lleva siete días, lo cual es mucho más largo que otros L1s. El desafío es abordar el tiempo de espera de siete días para los puentes oficiales de los rollups optimistas. La presentación de zkp también tiene un retraso temporal, ya que los rollups suelen esperar a acumular un gran lote de transacciones antes de enviar pruebas para ahorrar costos de verificación. Los rollups populares como StarkEx suelen publicar pruebas en L1 solo una vez cada pocas horas.
   2. Los datos de transacción de Rollups enviados a la capa de DA/liquidación tendrán un retraso temporal para ahorrar costos (1-3 minutos para rollups optimistas y unas pocas horas para rollups zk como se mencionó anteriormente). Esto debe ser abstraído de los usuarios que necesitan una finalidad más rápida y segura.

La buena noticia es que hay soluciones emergentes a estos desafíos:

1. Problema de fragmentación:
   1. Si bien hay una proliferación de rollups en el ecosistema, es notable que la mayoría de los rollups de contratos inteligentes comparten actualmente una capa de liquidación común, a saber, Ethereum. Las principales distinciones entre estos rollups radican en sus capas de ejecución y secuenciación. Para lograr la interoperabilidad, simplemente necesitan verificar mutuamente el estado final de la capa de liquidación compartida. Sin embargo, el escenario se vuelve ligeramente más intrincado para los rollups soberanos. Su interoperabilidad es algo desafiante debido a las diferentes capas de liquidación. Un enfoque para abordar esto es establecer un mecanismo de liquidación Peer-to-Peer (P2P), donde cada cadena incrusta directamente un cliente ligero del otro, facilitando la verificación mutua. Alternativamente, estos rollups soberanos pueden primero conectar con un centro de liquidación centralizado, que luego sirve como conducto para conectarse con otras cadenas. Este enfoque centrado en el centro agiliza el proceso y garantiza una interconexión más cohesiva entre diversos rollups. (similar al estado de interoperabilidad de cosmos)

1. Además de Ethereum que sirve como uno de los centros de liquidación, otros posibles centros de liquidación incluyen Arbitrum, zkSync y StarkNet, que actúan como centros de liquidación para L3s construidos sobre ellos. La capa de interoperabilidad de Polygon 2.0 también funciona como un centro central para rollups zk construidos sobre ella.
2. En conclusión, si bien el número de rollups y sus variaciones está aumentando, la cantidad de centros de liquidación sigue siendo limitada. Esto simplifica eficazmente la topología, reduciendo el problema de fragmentación a solo unos pocos centros clave. Aunque habrá más rollups que altl1s, las interacciones entre rollups son menos complicadas que las interacciones entre l1, ya que los rollups suelen estar dentro de la misma zona de confianza / seguridad.
3. Cómo se interoperan los diferentes centros de liquidación entre sí puede hacer referencia a cómo interoperan entre sí las cadenas monolíticas actuales, como se mencionó al principio.

Además, en un esfuerzo por eliminar la fragmentación en el lado del usuario, ciertas Capas 2, como ZKSync, han integrado la Abstracción de Cuenta nativa para facilitar una experiencia de transferencia entre rollups sin problemas.

1. Problema extensible
   1. Hyperlane(proporciona seguridad modular para cadenas modulares) y Catalyst(Liquidez sin permisos entre cadenas) nacieron para resolver el problema de interoperabilidad con permisos.
      1. La esencia de Hyperlane es crear una capa de seguridad estandarizada que se puede aplicar en varias cadenas, lo que las hace inherentemente interoperables.
      2. Catalyst está diseñado para ofrecer liquidez sin permisos para cadenas modulares. Actúa como un puente, permitiendo que cualquier nueva cadena se conecte a la liquidez e intercambie con importantes centros como Ethereum y Cosmos de forma transparente.
   2. Los proveedores de SDK/RAAS Rollup ofrecen servicios de puente nativos dentro de su ecosistema
      1. Ahora, los nuevos rollups se lanzan principalmente a través de SDK de rollup existentes o servicios RAAS, por lo que son inherentemente interoperables con otros rollups que utilizan los mismos servicios. Por ejemplo, para la infraestructura construida con el OP Stack, el nivel fundamental es un estándar de puente compartido, que permite el movimiento sin problemas de activos en todo lo que comparte la base de código de OP Stack. Para los rollups lanzados a través de altlayer, todos están consagrados en la capa de referencia, que actúa como el centro de liquidación y garantiza la interoperabilidad segura. Para los rollups lanzados a través de sovereign labs o zksync, son interoperables entre sí de forma predeterminada basándose en la agregación de pruebas (explicaré más adelante).

Problema de UE:

1. Antes de sumergirnos en esta parte, primero reconozcamos los diferentes niveles de compromiso y su retraso temporal:

1. Algunas partes se sienten cómodas con los compromisos suaves en la etapa 1 de l2, por ejemplo, los intercambios como Binance solo esperan un cierto número de bloques de Layer2 para considerar las transacciones como confirmadas, sin necesidad de esperar a que se envíe el procesamiento por lotes a Layer12. Algunos proveedores de puentes como el protocolo hop tomarían tantos bloques en la cadena de envío y determinarían la finalidad basándose en el consenso de L1 (etapa 2). Para puentes con minimización de confianza y para que los usuarios retiren los fondos de l2-l1 utilizando el puente oficial, podría llevar demasiado tiempo (varias horas y 7 días)

1. Reducir tanto la Etapa 2 como la Etapa 3 ofrecería ventajas significativas, brindando una garantía más fuerte en un período de tiempo más corto para una experiencia de usuario más segura y rápida. Además, lograr un puente minimizado en confianza siempre ha sido un objetivo codiciado, especialmente a la luz de los frecuentes incidentes de seguridad con puentes.
2. Reducir el tiempo de liquidación final (7 días para rollups optimistas y varias horas para rollups zk), es decir, acortar la etapa 3
   1. Rollups híbridos (Prueba de Fraude + ZK): Este enfoque combina las fortalezas de las pruebas ZK y los rollups optimistas. Si bien la generación y verificación de pruebas pueden ser intensivas en recursos, solo se ejecuta cuando se cuestiona una transición de estado. En lugar de publicar una prueba ZK para cada lote de transacciones, la prueba se calcula y publica solo cuando se impugna un estado propuesto, similar a un rollup optimista. Esto permite un período de desafío más corto ya que la prueba de fraude se puede generar en un solo paso, y el costo de las pruebas ZK se evita en la mayoría de los escenarios.
      1. Es notable que los SVM rollups de Eclipse y LayerN utilizan risc0 para generar la prueba de fraude zk. El Stack de OP ha otorgado soporte a Risc0 y Mina para el desarrollo de la prueba de fraude zk. Además, Fuel ha introducido recientemente un método híbrido similar que admite múltiples probadores.
   2. Después de publicar datos en la capa DA, realice una verificación adicional de la corrección de la ejecución para aumentar el nivel de confianza, altos requisitos, igual que un nodo completo
      1. Cuando el secuenciador agrupa las txs en las capas DA de las rollups optimistas, asegura un orden canónico y DA para las txs de x-rollup. Por lo tanto, lo único que necesita ser confirmado es la ejecución: S1 == STF(S0, B1). Por supuesto, puedes simplemente ejecutar un nodo completo (altos requisitos) para verificar la tx, pero lo que realmente queremos es reducir la latencia para los clientes ligeros. Las redes probadoras como @SuccinctLabsy@RiscZeropuede confirmar el estado post-ejecución proporcionando pruebas de estado concisas. Esto proporciona una confirmación sólida para dapps y usuarios.
      2. Altlayer tiene una capa de baliza entre los rollups y L1. Los secuenciadores de la capa de baliza son responsables de la secuenciación, ejecución y generación de pruebas de validez (POV). POV permite a los verificadores verificar una transición de estado para un rollup posterior sin tener acceso al estado completo. Con verificadores descentralizados realizando controles periódicos, hemos logrado una finalidad de transacción altamente robusta. No es necesario esperar 7 días, ya que los verificadores ya han completado las verificaciones necesarias. Como resultado, el envío de mensajes entre cadenas se ha vuelto más rápido y seguro.
      3. EigenSettle garantiza la verificación a través de mecanismos económicos. Los nodos de EigenLayer que optan por participar con apuestas realizan el cálculo para asegurar la validez del estado y utilizan su garantía para respaldar sus compromisos. Cualquier cantidad que sea inferior a la cantidad de apuesta que estos operadores han publicado puede considerarse como segura y permite la interoperabilidad respaldada económicamente.
   3. Verificación instantánea con ZK Rollups:
      1. Sovereign Labs y Polygon 2.0 emplean un enfoque innovador para lograr una finalización rápida al eludir la capa de liquidación. En lugar de esperar para enviar la prueba a Ethereum, podemos difundir instantáneamente las pruebas zk generadas a través de una red peer-to-peer y realizar operaciones entre cadenas basadas en los zkps propagados. Más adelante, podemos utilizar la recursión para consolidarlos en una prueba por lotes y enviarla a la Capa 1 cuando sea económicamente viable.
         1. Aunque no esté completamente resuelto, aún necesitamos confiar en la correcta agregación de la zkp. El Agregador de Polygon 2.0 puede operar de manera descentralizada, involucrando validadores de Polygon de la pool de validadores compartida, mejorando así la vitalidad de la red y la resistencia a la censura. Sin embargo, el uso de este método también conducirá a un tiempo de finalización más corto, ya que la agregación de zkps de múltiples cadenas es ciertamente más rápida que esperar zkps suficientes en una sola cadena.
      2. Los hyperchains de Zksync utilizan el método de capas para agregar zkp y lograr una finalización más corta. A diferencia de liquidar en L1, los hyperchains pueden liquidar sus pruebas en L2 (convertirse en l3). Este enfoque facilita el envío rápido de mensajes, ya que el entorno rentable en L2 permite una verificación rápida y económicamente viable.
         1. Para mejorar aún más la escalabilidad, podemos reemplazar el asentamiento L2 con un programa mínimo necesario para operar L3 con mensajería. Este concepto ha sido sustentado a través de pruebas especializadas que permiten la agregación.
3. Abordar el desfase de tiempo en la contabilización en la capa DA (también se pueden aplicar algunos métodos para reducir el período de liquidación), es decir, acortar la etapa2
   1. Capa de Secuenciación Compartida: Si los rollups comparten una capa de secuenciación (por ejemplo, a través de un servicio de secuenciador compartido o utilizando el mismo conjunto de capas de secuenciación), pueden obtener una confirmación suave del secuenciador. Esto, combinado con un mecanismo económico, garantiza la integridad del estado final. Las combinaciones posibles incluyen:
      1. Secuenciador compartido sin estado + constructor hace promesa de ejecución mediante apuesta propuesta por Espresso; Este enfoque es más adecuado para rollups con estructura PBS, asumiendo que el constructor de bloques ya tiene los derechos necesarios para partes de los bloques. Dado que el constructor tiene estado y sirve como el rol de ejecución subyacente para los secuenciadores compartidos, es natural que haga promesas adicionales.
      2. Secuencia de validez compartida propuesta por la investigación de Umbra: secuenciador compartido con estado + prueba de fraude para garantizar un buen comportamiento. Los secuenciadores aceptan solicitudes entre cadenas. Para evitar comportamientos deshonestos por parte de los secuenciadores, se utiliza un mecanismo de prueba de fraude compartido, que implica pequeños cambios en el mecanismo de prueba de fraude original de rollup. Durante el período de desafío, los desafiantes también verificarían la ejecución correcta de acciones atómicas. Esto puede implicar verificar las raíces de contratos de puente en diferentes rollups o examinar la prueba de Merkle proporcionada por los secuenciadores. Los secuenciadores deshonestos son penalizados.
   2. Intervención de terceros: Entidades externas como Hop, Connext y Across pueden intervenir para mitigar los riesgos. Validan los mensajes y aportan el capital para las actividades financieras entre cadenas de los usuarios, reduciendo efectivamente el período de espera. Por ejemplo, Boost (GMP Express) es una característica especial de Axelar y Squid que reduce el tiempo de transacción entre cadenas a 5-30 segundos para intercambios por debajo de un valor de $20,000 USD.
   3. Infraestructura de Intención para la conexión como una forma específica de intervención de terceros: Esta infraestructura renovada puede abarcar a más terceros para intervenir y resolver las intenciones entre dominios para los usuarios.
      1. A través de una arquitectura centrada en la intención (eliminando fricciones y complejidades de los usuarios al involucrar a actores sofisticados como MMs y constructores), los usuarios transmiten su objetivo o resultado previsto sin detallar las transacciones precisas necesarias para realizarlo. Las personas con una alta tolerancia al riesgo pueden intervenir, aportar el capital necesario y cobrar tarifas más altas.
      2. Es más seguro porque los fondos de los usuarios solo se liberarían cuando el resultado sea válido. Podría ser más rápido y flexible porque más partes (solucionadores) están involucradas sin necesidad de permiso en el proceso de resolución y compiten para dar un mejor resultado a los usuarios.
      3. UniswapX, SUAVE de flashbots y essential están trabajando en esta dirección. Más sobre intenciones: \
         nft://10/0x9351de088B597BA0dd2c1188f6054f1388e83578/?showBuying=true&showMeta=true
      4. El aspecto desafiante de esta solución se centra en el oráculo de liquidación. Tomemos UniswapX como ejemplo. Para facilitar intercambios entre cadenas, dependemos de un oráculo de liquidación para determinar cuándo liberar los fondos a los solucionadores. Si el oráculo de liquidación opta por el puente nativo (que es lento), o si se utiliza un puente de terceros (generando preocupaciones de confianza), o incluso si es un puente de Cliente Ligero (que aún no está listo para su uso), básicamente nos encontramos en el mismo bucle que antes. Por lo tanto, UniswapX también ofrece "intercambios rápidos entre cadenas" similares a un puente optimista.
      5. Al mismo tiempo, la efectividad de la resolución de intenciones depende de la competencia entre los solucionadores. Dado que los solucionadores necesitan reequilibrar su inventario en diferentes cadenas, esto podría potencialmente conducir a problemas de solucionadores centralizados, limitando el potencial completo de las intenciones.

Para resumir, se puede observar que hay tres formas de abordar los problemas de UE:

1. Utiliza la magia de zk :
   1. El principal desafío radica en el rendimiento de la tecnología zk, que abarca tanto el tiempo requerido para la generación como los costos asociados. Además, al tratar con blockchains modulares altamente personalizables, surge la pregunta: ¿poseemos un sistema de prueba zk capaz de acomodar la variedad de diferencias?
2. Utilice un esquema de recorte económico para garantizar :
   1. La principal desventaja de este enfoque es la demora inherente en el método descentralizado (por ejemplo, en el caso de EigenSettle, debemos esperar a que se alcance el límite). Además, el enfoque centralizado ofrece compromisos limitados (como se ejemplifica con la secuenciación compartida), dependiendo de los constructores/sequencers para hacer compromisos, que pueden ser restringidos y carecer de extensibilidad.
3. Confía en un tercero :
   1. Si bien confiar en un tercero puede introducir riesgos adicionales, ya que los usuarios deben tener fe en el puente, los intercambios habilitados para la intención representan una forma algo más "descentralizada" de puente de terceros. Sin embargo, este enfoque aún enfrenta la latencia del oráculo, problemas de confianza y posibles retrasos temporales, ya que debe esperar a que alguien acepte su intención.

Es interesante que la modularización también introduce nuevas posibilidades para las experiencias de interoperabilidad:

1. Velocidad mejorada con componentes modulares: al dividirse en módulos más finos, los usuarios pueden obtener confirmaciones más rápidas desde el nivel de capa 2 (que podría ser lo suficientemente seguro para usuarios ordinarios)
2. Secuenciador compartido para transacciones atómicas: El concepto de un secuenciador compartido podría potencialmente permitir una nueva forma de transacciones atómicas, como préstamos flash. Más detalles en : https://twitter.com/sanjaypshah/status/1686759738996912128

Las soluciones de interoperabilidad modular están experimentando un crecimiento rápido y actualmente existen diversos enfoques, cada uno con sus propias fortalezas y debilidades. Quizás la solución definitiva todavía esté lejos, pero es alentador ver a tantas personas esforzándose por crear un mundo modular más seguro y conectado antes de que llegue la explosión de rollup.

Análisis de Costos

Un factor que contribuye a la cantidad limitada de rollups existentes es la consideración económica asociada con su lanzamiento, en comparación con la utilización de contratos inteligentes. Operar a través de contratos inteligentes adopta un modelo de costos más variable, donde el gasto principal es la tarifa de gas, mientras que el lanzamiento y mantenimiento de un rollup conlleva costos fijos y variables. Esta dinámica de costos sugiere que las aplicaciones con un volumen de transacciones sustancial o tarifas de transacción relativamente altas están mejor posicionadas para aprovechar los rollups, ya que tienen una mayor capacidad para amortizar los costos fijos involucrados. En consecuencia, las iniciativas destinadas a reducir el costo asociado con los rollups, tanto fijos como variables, son fundamentales. Adentrarse en los componentes de costos de los rollups, como lo explicaron Neel y Yaoqi durante su charla en ETHCC, proporciona una imagen más clara:

Emplear un modelo financiero, como el análisis de flujo de caja descontado (DCF), puede ser fundamental para evaluar la viabilidad de lanzar un rollup para una aplicación. La fórmula:

DCF(Ingresos - Gastos)>Inversión Inicial

sirve como un punto de referencia para determinar si el ingreso operativo supera la inversión inicial, lo que convierte el lanzamiento de un rollup en una decisión financieramente sólida. Los protocolos que logran reducir los costos operativos mientras aumentan los ingresos son fundamentales para fomentar la mayor adopción de rollups. Vamos a explorar uno por uno:

1. Cuota inicial de desarrollo e implementación
   1. La configuración inicial, a pesar de la disponibilidad de SDK de código abierto como Opstack y Rollkit, aún exige una cantidad significativa de tiempo y capital humano para la instalación y depuración. Las necesidades de personalización, por ejemplo, la integración de una máquina virtual en un SDK, aumentan aún más los recursos necesarios para alinear la máquina virtual con las distintas interfaces que proporciona cada SDK.
   2. Los servicios RAAS como AltLayer y Caldera pueden aliviar significativamente estas complejidades y esfuerzos, encapsulando los beneficios económicos de la división del trabajo.
2. Tarifa/Ingresos recurrentes
   1. Ingresos （++++）
      1. Tarifas de usuario
         1. = Tarifa de publicación de datos de Nivel 1 + Tarifa de operador de Nivel 2 + Tarifa de congestión de Nivel 2
         2. Aunque algunas tarifas de usuario pueden ser compensadas por gastos, es vital examinar y esforzarse por reducir estos costos, ya que los rollups pueden volverse insostenibles si las tarifas de usuario son prohibitivamente altas para los usuarios. (Explorado en la sección de gastos)
      2. Valor Extraíble por el Minero (MEV) capturado
         1. Principalmente relacionado con el valor de transacción originario de la cadena, esto puede ser impulsado ya sea mejorando la eficiencia de extracción de MEV o aumentando el MEV entre dominios.
         2. Asociarse con buscadores establecidos, emplear una subasta PBS para fomentar la competencia, o aprovechar el servicio de construcción de bloques de SUAVE son estrategias viables para optimizar la eficiencia de captura de MEV.
         3. Para capturar más MEV entre cadenas, utilizar una capa de secuenciador compartida o SUAVE (memoria compartida y construcción de bloques compartida) es beneficioso, ya que se conectan a varios dominios.
            1. Segúninvestigaciones recientespor Akaki, los secuenciadores compartidos son valiosos para los buscadores de arbitraje que buscan aprovechar oportunidades de arbitraje en diferentes cadenas, ya que aseguran la victoria en carreras simultáneas en todas las cadenas.
            2. SUAVE sirve como una capa de agregación de flujo de pedidos multi-dominio, ayudando al constructor/buscador a explorar MEV entre dominios.
   2. Gastos （- - - -)
      1. Tarifa de operación de Capa 2 (L2)
         1. Ordenar: Puede ser complicado comparar soluciones de ordenación centralizadas y descentralizadas. La competencia en soluciones más descentralizadas como Prueba de Eficiencia puede ayudar a reducir costos manteniendo el margen del operador mínimo e incentivando la publicación de lotes con la mayor frecuencia posible. Por otro lado, las soluciones centralizadas generalmente implican menos partes, lo que puede simplificar el proceso pero no beneficiarse de las mismas dinámicas de reducción de costos.
         2. Ejecución: Aquí es donde los nodos completos utilizan máquinas virtuales (VM) / máquinas virtuales Ethereum (EVM) para ejecutar los cambios en el estado de un rollup dados los nuevos cambios de usuario.
            1. La eficiencia puede reforzarse a través de máquinas virtuales alternativas optimizadas como Fuel y la Solana VM de Eclipse, que permiten la ejecución paralela. Sin embargo, alejarse de la compatibilidad con EVM podría introducir fricciones para los desarrolladores y usuarios finales, junto con posibles problemas de seguridad. La compatibilidad del Stylus de Arbitrum tanto con EVM como con WASM (que es más eficiente que EVM) es encomiable.
         3. Demostración
            1. Mercado Prover
               1. Teóricamente, el uso de un mercado especializado de probadores como Risc0, =nil y marlin, en lugar de crear una red de probadores centralizada o descentralizada propia, puede resultar en ahorros de costos por varias razones:
                  1. Puede haber un nivel más alto de participación en un mercado de probadores dedicado, lo que a su vez fomenta una mayor competencia, lo que finalmente lleva a precios más bajos.
                  2. Los probadores pueden optimizar el uso del hardware y reutilizarse cuando una aplicación específica no requiere la generación inmediata de pruebas, lo que reduce los costos de operación y proporciona un servicio más barato.
                  3. Naturalmente, hay desventajas, incluido capturar potencialmente menos utilidad del token y depender del rendimiento de una parte externa. Además, distintos zk rollups pueden imponer requisitos de hardware variables para el proceso de generación de prueba. Esta variabilidad podría plantear un desafío para los probadores que buscan expandir sus operaciones de demostración.
                  4. más sobre el mercado de Gate y la red de Gate: https://figmentcapital.medium.com/mercados-de-prueba-decentralizados-e-infraestructura-zk-f4cce2c58596
      2. Capa 1 (L1) publicación de datos
         1. Optar por una capa de Disponibilidad de Datos (DA) más rentable aparte de Ethereum o incluso usar una solución DAC puede reducir significativamente los gastos, aunque a costa potencial de una menor seguridad (explorada más adelante en la capa de seguridad). Para juegos y redes sociales, que suelen tener un valor bajo pero un ancho de banda alto, la escalabilidad podría ser un factor más importante que la seguridad para ellos.
         2. Emplear Ethereum como la capa DA permite aprovechar el protodansharing y el dansharding para lograr eficiencia de costos. Además, dado que la tarifa de publicación de blob se establece por bloque independientemente de la utilización del blob por el rollup, existe la necesidad de equilibrar entre el costo y la demora: Si bien idealmente un rollup publicaría un blob completo, una baja tasa de llegada de transacciones que resulta en ocupar completamente un espacio de blob conlleva a costos excesivos de demora.
            1. Posibles soluciones: costo conjunto de publicación de bloques para rollups pequeños;
      3. Tarifa de liquidación L1
         1. Para rollups optimistas, el costo de liquidación es relativamente bajo. Después de bedrock, Optimismo solo paga ~5$ al día a ethereum;
         2. Para el asentamiento zk, es relativamente caro para la verificación zkp
            1. agregación de pruebas zk
               1. Dependiendo del sistema de prueba subyacente, un rollup en Ethereum podría gastar desde 300k hasta 5m de gas para validar una sola prueba. Pero dado que los tamaños de prueba crecen muy lentamente (o no lo hacen en absoluto) con el número de transacciones, los rollups pueden reducir su costo por transacción esperando acumular un gran lote de transacciones antes de enviar una prueba.
               2. Los laboratorios soberanos, la capa de interoperabilidad de polygon 2.0 como se mencionó anteriormente, agrega pruebas de múltiples rollups, cada rollup puede luego verificar el estado de múltiples rollups al mismo tiempo, ahorrando en costos de verificación. La estructura de capas de Zksync combinada con la agregación de pruebas reduce aún más los costos de verificación.
               3. Sin embargo, este método es más efectivo cuando dos dominios utilizan el mismo ZKVM o un esquema de probador compartido (las hypercadenas de zksync utilizan el mismo zkEVM con circuitos zkp completamente idénticos); de lo contrario, puede resultar en un rendimiento comprometido.
                  1. Los laboratorios NEBRA aportan economías de escala y composabilidad de verificación de pruebas en Ethereum. NEBRA UPA (Agregador de Pruebas Universal) agrega universalmente pruebas heterogéneas para que el costo de verificación pueda amortizarse. UPA se puede utilizar para componer pruebas de diferentes fuentes y permitir nuevos casos de uso.

En resumen, los métodos principales para economizar en los costos de rollup incluyen:

1. Co-agregando con otros rollups para compartir tarifas o aprovechar economías de escala:
   1. Es importante destacar que dicha agregación también es potencialmente crucial para lograr la interoperabilidad. Como se destacó anteriormente, emplear una capa o marco congruente en diversos rollups simplifica la interacción entre ellos, garantizando un intercambio de información sin problemas. Esta estrategia consolidada fomenta una infraestructura de Capa 2 más integrada y unificada.
2. Delegar ciertas tareas a proveedores de servicios externos, capitalizando en el principio de división del trabajo.

A medida que surjan más rollups (lo que significa que puedes colaborar con partes adicionales para dividir tarifas), y más proveedores de servicios de rollup ofrezcan servicios más refinados (proporcionando una selección más amplia de proveedores upstream maduros), anticipamos que los gastos asociados con el establecimiento de un rollup disminuirán.

Seguridad compartida

Si tu objetivo es lograr un nivel equivalente de seguridad (tanto económicamente como en cuanto a descentralización) como la cadena fuente, simplemente implementa un contrato inteligente o un contrato inteligente rollup. Si aprovechar una parte de la seguridad proporcionada por la cadena fuente es suficiente para mejorar el rendimiento, actualmente existen varias soluciones de seguridad compartida a tu disposición.

Las soluciones de seguridad compartida facilitan en gran medida el proceso de arranque de seguridad de la mayoría de los protocolos o capas modulares que necesitan seguridad inicial. Esto es muy significativo para un mundo modular futuro, ya que visualizamos más infra/protocolos emergiendo para facilitar la funcionalidad de un mundo modular y más partes de un rollup se vuelven modulares, excepto por DA, ejecución, liquidación y secuenciación. Si un rollup utiliza una cierta capa modular (como DA) o un servicio cuya seguridad no está a la altura de la de Ethereum, entonces la seguridad general de toda la cadena modular podría estar comprometida. Necesitamos seguridad compartida para habilitar una economía de servicios SAAS descentralizada y confiable.

Eigenlayer, la seguridad de malla de Babylon y Cosmos ICS y Osmosis desempeñan un papel fundamental en ofrecer confianza descentralizada como servicio a otras entidades infraestructurales.

1. Eigenlayer permite a los validadores de Ethereum reutilizar su $ETH bloqueado para asegurar otras aplicaciones construidas en la red.
2. La ICS de Cosmos permite que el Cosmos Hub (cadena proveedora) preste su seguridad a otras blockchains (cadenas consumidoras) a cambio de tarifas.
3. La seguridad de Mesh, impulsada por la ósmosis, permite a los delegantes de tokens (no validadores) volver a apostar sus tokens apostados en una cadena asociada dentro del ecosistema. Esto permite un flujo de seguridad bidireccional o multilateral, ya que diferentes appchains pueden combinar sus mcaps para mejorar la seguridad general.
4. Babylon permite a los titulares de BTC apostar su BTC dentro de la red BTC y proporcionar seguridad a otras cadenas POS optimizando el uso del lenguaje de scripting de Bitcoin y utilizando un mecanismo criptográfico avanzado

ICS y Mesh Security, ambos parte integral del ecosistema de Cosmos, tienen como objetivo principal facilitar el préstamo de seguridad entre cadenas. Estas soluciones abordan principalmente las necesidades de seguridad de las cadenas de aplicaciones de Cosmos, lo que les permite aprovechar la seguridad de otras cadenas dentro del ecosistema. En concreto, Cosmos Hub ICS ofrece para las cadenas de cosmos que no desean arrancar conjuntos de validadores (seguridad replicada), mientras que la seguridad de malla requiere que cada cadena tenga su propio conjunto de validadoresb, pero permite una opcionalidad mucho mayor para la gobernanza de la cadena.

Por otro lado, Babilonia presenta un enfoque único al desbloquear el potencial latente de los activos inactivos de los titulares de BTC sin mover BTC de su cadena nativa. Al optimizar el uso del lenguaje de script de Bitcoin e integrar mecanismos criptográficos avanzados, Babilonia proporciona seguridad adicional a los mecanismos de consenso de otras cadenas con características excelentes como períodos de desvinculación más rápidos. Los validadores en otras cadenas POS con BTC pueden bloquear su BTC en la red de Bitcoin y firmar bloques POS con claves privadas de BTC. Actuaciones inválidas como la doble firma filtrarían la clave privada de btc del validador y quemarían su BTC en la red de bitcoin. El staking de BTC se lanzaría en el segundo testnet de Babilonia.

Mientras que Babilonia navega por las limitaciones de la falta de soporte de contratos inteligentes de Bitcoin, los operadores de Eigenlayer en la plataforma Ethereum, que es Turing-completa, no solo ofrecen seguridad económica a los nuevos rollups y cadenas, sino que su entorno en Ethereum también permite una gama más diversa de AVS. Según el artículo de eigenlayer sobre confianza programable, La seguridad que puede proporcionar Eigenlayer se puede dividir en 3 tipos:

1. Confianza económica: Confianza de los validadores que hacen compromisos respaldando sus promesas con apuestas financieras. Este modelo de confianza asegura consistencia independientemente del número de partes involucradas. Deben existir condiciones de penalización objetivas que puedan ser presentadas y verificadas en la cadena, y generalmente es de gran peso para los que vuelven a apostar.
2. Confianza descentralizada: confianza derivada de tener una red descentralizada operada por operadores independientes y geográficamente aislados. Este aspecto enfatiza el valor intrínseco de la descentralización y permite casos de uso que no son objetivamente demostrables, ya que la descentralización aumenta la dificultad de colusión. Para aprovechar la confianza descentralizada, suele ser ligero.
3. Fideicomiso de inclusión de Ethereum: confianza en que los validadores de Ethereum construirán e incluirán sus bloques como se prometió, junto con el software de consenso que están ejecutando. Esto puede ser específicamente comprometido por los validadores de Ethereum (no por los que reestacan el LST). Ejecutan complementos de software para realizar cálculos adicionales y recibir recompensas adicionales.

Entonces, ahora que tenemos claros los materiales de seguridad, ¿qué podemos esperar?

1. ICS y la seguridad de malla bajan las barreras de seguridad para las appchains de cosmos como neutron, stride y axelar.
2. Eigenlayer puede encajar en muchas soluciones que se han mencionado anteriormente:
   1. seguridad de rollup: red de retransmisión; torre de vigilancia, secuenciación, protección contra MEV, eigenDA
   2. interoperabilidad de rollup: eigensettle; puentes
   3. análisis de costos: red de probadores
   4. más por explorar, echa un vistazo https://www.blog.eigenlayer.xyz/eigenlayer-universe-15-unicorn-ideas/
3. Babylon está ejecutando una red de prueba para aumentar el nivel de seguridad de otras cadenas de puntos de venta. Su primera red de prueba proporciona un servicio de marca de tiempo para agregar seguridad adicional a las actividades defi de alto valor de varias cadenas de cosmos como akash, ósmosis, juno, etc.

La idea principal detrás de estas soluciones de seguridad compartida es mejorar la eficiencia de capital de los activos apostados o ilíquidos mediante la introducción de responsabilidades adicionales. Sin embargo, es esencial ser vigilante acerca de los riesgos adicionales al buscar mayores rendimientos:

1. La mayor complejidad introduce más incertidumbres. Los validadores quedan expuestos a condiciones adicionales de penalización que pueden carecer de suficientes medidas de seguridad, lo que puede ser peligroso.
   1. Eigenlayer pretende abordar esta cuestión proponiendo la puesta en marcha de un comité de veto. Este comité sirve como una entidad de confianza mutua entre los stakers, los operadores y los desarrolladores de AVS. En el caso de un error de software dentro del AVS, los stakers y operadores no se enfrentarán a sanciones, ya que el comité de veto puede emitir un voto de veto. Si bien este enfoque puede no ser inherentemente escalable y podría ser subjetivo si los AVS no están estrictamente alineados con los casos de uso basados en acciones atribuibles sin confianza, aún puede servir como un medio valioso para iniciar una estrategia de mitigación de riesgos durante las primeras etapas.
2. Una mayor complejidad también conlleva cargas adicionales. Puede resultar abrumador para validadores menos experimentados determinar con qué servicio compartir seguridad. Además, el período de configuración inicial puede implicar un mayor riesgo de errores. Asimismo, deberían existir mecanismos para permitir que los validadores y apostadores menos entendidos en tecnología se beneficien de rendimientos más altos, siempre que estén dispuestos a asumir riesgos relativamente elevados, sin estar limitados por sus capacidades operativas.
   1. La red Rio y Renzo están trabajando en abordar de manera efectiva este desafío para Eigenlayer al ofrecer un enfoque estructurado para seleccionar con cautela operadores de nodos sofisticados y servicios AVS para posibles reestacas, elevando los niveles de seguridad y reduciendo las barreras de entrada para los participantes.

Además, a medida que Eigenlayer gana una mayor adopción, podría potencialmente abrir nuevos horizontes en el ámbito de la Financialization of Security. Esto podría facilitar la valoración de la seguridad compartida y las diversas aplicaciones construidas sobre ella.

1. Una limitación que se le presenta a EigenLayer es su capacidad para escalar la asignación de capital a su sistema superando las oportunidades de rendimiento en DeFi para los mismos activos que admite (LST). EigenLayer mercantiliza el valor de la seguridad y esto abre la puerta para que muchas primitivas suscriban este valor y brinden la capacidad de que los restauradores vuelvan a apostar y participen en el ecosistema DeFi más amplio.
   1. Ion Protocol es un producto que intenta hacer esto para ampliar el alcance que puede tener la reposición. Ion está construyendo una plataforma de préstamos sin tener en cuenta el precio que está diseñada para respaldar específicamente activos con stake y reposicionados mediante el uso de infraestructura ZK para asegurar el riesgo de slashing a nivel inferior presente en dichos activos (sistemas de prueba de estado ZK + ZKML). Esto podría iniciar el comienzo del nacimiento de muchos nuevos primitivos DeFi construidos sobre el valor subyacente de seguridad que EigenLayer commoditizes, lo que permite aún más la capacidad de la reposición para escalar en todo el ecosistema.

A medida que nos encontramos en el umbral de transformaciones significativas, es crucial abrazar los principios de seguridad, interoperabilidad y rentabilidad. Estos pilares no solo guiarán el desarrollo de soluciones de blockchain más escalables y eficientes, sino que también allanarán el camino para un mundo digital más interconectado y accesible. Abrazar estos cambios con previsión y adaptabilidad sin duda conducirá a avances innovadores en el ecosistema blockchain.

Descargo de responsabilidad：

1. Este artículo es reproducido de [Gateespejo]. Todos los derechos de autor pertenecen al autor original [SevenX Ventures]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y ellos lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen asesoramiento de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.