El panorama de L1 frente a L2: diferencias de diseño, concesiones y objetivos finales

Información práctica

• Comprende las primitivas disponibles y las limitaciones técnicas: Conoce a fondo los componentes fundamentales y los matices técnicos. Este conocimiento es crucial para identificar cómo estos factores pueden afectar la funcionalidad y escalabilidad de tu aplicación y, en última instancia, tu negocio. También te permite tomar decisiones informadas durante el desarrollo en blockchain.
• Evalúa la infraestructura y la liquidez: Evalúa la infraestructura y liquidez disponibles en las soluciones L1 y L2, junto con entornos de ejecución alternativos para el despliegue. Proyecta el estado de la infraestructura a partir de los primeros principios. Comprende desde los primeros principios los supuestos reales de confianza y descentralización.
• Optimiza la experiencia del usuario: Optimiza sin descanso la experiencia del usuario. Considera la facilidad de uso, velocidad de las transacciones y eficiencia general de cada cadena. Busca crear un entorno fluido y fácil de usar, teniendo en cuenta lo que ya está disponible y hacia dónde conducen las hojas de ruta.

Introducción

A medida que evoluciona el panorama de las blockchains, decidir dónde crear aplicaciones se vuelve cada vez más complejo para los desarrolladores. Este informe analiza las diferencias entre las soluciones de capa 1 (L1) y capa 2 (L2) para plataformas generalizadas de contratos inteligentes, así como sus implicaciones para la participación de los usuarios, los márgenes económicos y el crecimiento empresarial.

A pesar de la diversidad y los avances de la industria blockchain, la base de usuarios sigue siendo modesta frente a las plataformas digitales convencionales. Por ejemplo, hoy las criptomonedas atraen alrededor de 5.5 millones de direcciones únicas atribuibles al día, frente a los cerca de 2 mil millones de usuarios diarios de plataformas como Facebook.

Hoy, los clientes de las blockchains son los desarrolladores. Las blockchains venden espacio de bloque a los desarrolladores de aplicaciones para que creen productos novedosos. Elegir dónde crear tu aplicación es una de las decisiones más importantes que enfrenta un desarrollador. Desde la perspectiva empresarial, también es una de las decisiones de mayor impacto, pues afecta a los posibles usuarios posteriores, la liquidez y la cultura. Migrar sistemas después del lanzamiento es una tarea difícil desde el punto de vista técnico y social, aunque no imposible. Equipos como dydx migraron con éxito de Ethereum a una appchain de Cosmos, mientras que y00ts enfrentó dificultades al migrar de Solana a Polygon y ahora a Ethereum.

Este informe no pretende adoptar una postura en el debate más reciente entre sistemas modulares e integrados. En cambio, ofrece una perspectiva práctica para que desarrolladores, posibles desarrolladores y ejecutivos comprendan mejor el panorama L1/L2, con ejemplos concretos de las concesiones que ciertos diseños imponen a las aplicaciones.

Características de una blockchain

Antes de analizar las diferencias entre L1 y L2, primero debemos definir las características de una blockchain.

Una blockchain es una máquina de estados replicada y determinista. Es un sistema complejo diseñado para alcanzar consenso y mantener un registro unificado y seguro en una red distribuida.

Determinista

Los procesos de una blockchain están predeterminados por el protocolo subyacente. Cuando la “función de transición de estado” (STF) de una blockchain se ejecuta con una entrada determinada y el estado actual, produce el mismo estado nuevo en todos los nodos. Esta naturaleza determinista garantiza un resultado uniforme, sin importar quién ejecute la función o qué nodo procese la transacción. Los procesos deterministas garantizan confiabilidad y previsibilidad en las operaciones de la red.

Replicada

Las blockchains aprovechan una red de nodos, cada uno de los cuales mantiene una copia del estado completo de la blockchain. Esta replicación contribuye a la descentralización y ofrece resistencia frente a la pérdida y manipulación de datos. Como cada nodo conserva una réplica del estado, cualquier intento de alterar el registro histórico requeriría modificar simultáneamente la mayoría de los nodos. Esto resulta prácticamente inviable en una red suficientemente grande y distribuida.

Máquina de estados

En esencia, una blockchain es un sistema que administra estados: instantáneas de un momento específico que contienen toda la información acordada, como saldos de cuentas, estados de contratos inteligentes y registros de propiedad. La blockchain cambia de estado mediante transacciones, que son solicitudes para pasar de un estado al siguiente. Las reglas codificadas en el protocolo de la blockchain rigen estas transiciones.

Estas propiedades producen un libro contable que cualquiera puede leer o modificar. Como Balaji señaló en 2019, las blockchains públicas son bases de datos globales multicliente donde cada usuario es un usuario raíz. Esto permite una visión global de cuántos activos (tokens, NFT, etc.) posee cada usuario, así como innovar sin permisos sobre un estado público, global y compartido.

Participantes del mercado blockchain

Las blockchains facilitan un mercado global de información acordada, basado en la confianza descentralizada. En una red blockchain hay dos partes interesadas principales:

• Proveedores de confianza: participantes de staking, validadores y mineros (según si la red utiliza PoW o PoS)
• Consumidores de confianza: aplicaciones (que suelen agrupar transacciones y trasladar al usuario el costo operativo marginal)

En otras palabras, las blockchains facilitan un mercado bilateral entre compradores y vendedores, como cualquier otro mercado económico. De acuerdo con la oferta y la demanda, el mercado fija un costo por facilitar el intercambio entre ambas partes.

Las blockchains públicas necesitan comisiones para evitar el spam y asignar recursos escasos. Estas comisiones son la principal forma de compensación e ingresos de los validadores y mineros para cubrir gastos generales como equipos, electricidad y otros recursos. Aunque los protocolos usan distintos mecanismos para fijar las comisiones, todas las principales blockchains públicas integran el gas en el protocolo de alguna manera. Alguien opera equipos informáticos en algún lugar del mundo y necesita recibir una compensación que lo incentive.

Definición de L1 y L2

Ahora que comprendemos mejor qué es una blockchain y qué permite hacer, podemos formalizar las definiciones de L1 y L2.

Una definición integral y rigurosa de L1 y L2, junto con sus respectivas connotaciones, es motivo de debate entre los investigadores y la comunidad cripto en general. Han surgido distintas variantes de rollups (optimistas, de conocimiento cero e integrados en el protocolo), con diferencias en su implementación y sus supuestos de confianza (validiums, volitions y soberanos, entre otros).

Antes de analizar las concesiones entre L1 y L2, debemos definirlas.

Capas 1 (L1)

Las blockchains L1 son redes fundamentales que funcionan como infraestructura principal de una criptomoneda. Son redes independientes con sus propios protocolos subyacentes, mecanismos de consenso y tokens nativos. Las L1 suelen denominarse la capa base de un ecosistema blockchain porque proporcionan el marco fundamental de seguridad y gobernanza.

Ethereum fue pionera en el concepto de confianza modular cuando se lanzó en 2015. Sin embargo, Ethereum no estaba y todavía no está optimizada para la escala necesaria para incorporar a millones de usuarios. Como resultado, aparecieron nuevas soluciones de escalabilidad, como los rollups, que prometen aumentar la escala de Ethereum.

Capas 2 (L2)

Las soluciones L2 se construyen sobre blockchains L1 para mejorar la escalabilidad y el rendimiento de las transacciones sin modificar la capa base. Los rollups son una de las soluciones L2 más prometedoras y estudiadas.

Los rollups descargan transacciones de la L1, las procesan por separado y luego registran el estado final nuevamente en la L1, a menudo como una raíz de estado. Este enfoque permite que el propio rollup ejecute más transacciones en un entorno de estado separado y a un costo menor que si lo hiciera directamente en la L1. Los rollups agrupan o “enrollan” varias transacciones en una sola transacción en la L1 para reducir la carga y mejorar la eficiencia. Las distintas soluciones L2 tienen diferentes supuestos de confianza y, en general, buscan heredar las propiedades de seguridad y descentralización de la L1 subyacente. Así ofrecen alternativas seguras, pero más escalables, que procesar cada transacción en la L1.

Celestia formalizó esta definición de los rollups:

En la práctica, Ethereum tiene los activos más interesantes y nominalmente valiosos del ecosistema cripto. Los usuarios han demostrado que están dispuestos a transferir sus activos mediante puentes a distintas soluciones L2 para obtener comisiones mucho menores que en la red principal de Ethereum, sin preocuparse demasiado por algunos aspectos centralizadores de las L2. Estos aspectos están en desarrollo activo, pero a menudo todavía no están disponibles. 

La seguridad es una preocupación habitual al transferir activos mediante puentes entre cadenas. Aunque muchos puentes de rollups importantes carecen de sistemas de pruebas rigurosos y han recibido críticas por sus posibles puntos de control centralizados, ofrecen una extensión fluida de la experiencia de Ethereum mediante una experiencia similar a la EVM y una infraestructura uniforme de billeteras. Rollups como Base, Optimism y Arbitrum procuran conservar la billetera y dirección de Ethereum existentes del usuario, lo que hace mucho más fluidas las transiciones entre la cadena principal y las L2. Esta comodidad, sumada al dominio de ETH en DeFi y las aplicaciones sociales, convierte a L2 en una opción atractiva para quienes buscan familiaridad y facilidad de uso. Ethereum tiene el estado más popular con el que otros desarrolladores quieren interactuar, y las L2 se consideran una extensión natural de Ethereum.

Todo esto significa que “heredar” ciertas garantías de seguridad de Ethereum ocupa un lugar muy secundario entre los motivos por los que un equipo decide lanzarse como una L2 de Ethereum o migrar de una L1 independiente a una L2.

Nuevos desarrollos como Solang y Neon reducen la brecha para los desarrolladores acostumbrados a Solidity de Ethereum, mientras que Snaps de Metamask amplía la compatibilidad de las billeteras a cadenas que no usan EVM. Estos avances apuntan a un futuro donde la experiencia del usuario abstraiga eficazmente muchas complejidades entre distintos entornos de ejecución.

Aunque la Ethereum Foundation financió gran parte de la investigación sobre las L2, todas las L2 son entidades independientes y no están operadas por la Ethereum Foundation. La innovación sin permisos no es exclusiva de la capa de aplicaciones descentralizadas. Además, ninguna L1 con neutralidad creíble tiene la capacidad técnica para decidir qué L2 pueden desplegarse sobre ella.

Implementaciones y arquitectura “típicas” de L1 y L2

Para comprender bien las concesiones entre L1 y L2, es crucial conocer sus respectivas cadenas de suministro, participantes relevantes y supuestos de confianza.

Ciclo de vida de una transacción L1

Aunque cada L1 tiene detalles de implementación únicos, todas las L1 principales comparten partes interesadas y ciclos de vida de las transacciones similares. Esta sección describe el flujo habitual de una transacción, desde su generación hasta su inclusión final.

1. Intención

El usuario comienza con un objetivo o una acción clara que desea realizar en la red Ethereum, como enviar ETH, interactuar con un contrato inteligente o intercambiar tokens. Esta etapa comprende el proceso de decisión del usuario y su comprensión de lo que quiere lograr, lo cual traza el recorrido de la transacción.

2. Generación de la transacción

Aquí la transacción toma forma. El usuario, generalmente mediante una interfaz como una billetera o aplicación descentralizada, introduce la información necesaria: la dirección del destinatario, el importe que enviará o el método del contrato que desea invocar. Esta etapa convierte la intención del usuario en una solicitud estructurada que la red Ethereum puede procesar. En este punto, el usuario determina el costo de la transacción, que incluye el precio y el límite del gas. Esto depende en gran medida de la cadena y el proveedor de la billetera suele abstraerlo. Tanto Ethereum como Solana implementan una versión de este sistema mediante una comisión base y una comisión de prioridad (propina), con diferencias de implementación y distintos niveles de determinismo respecto a la inclusión de transacciones.

3. Transmisión

El usuario firma la transacción con su clave privada, una firma digital que demuestra su autorización. Una vez firmada, la transacción se transmite a la red, normalmente mediante un proveedor RPC integrado en la billetera. Por lo general, pasa por el mempool público o por subastas privadas de flujo de órdenes, donde espera su procesamiento.

4. Confirmación de inclusión

La transacción concluye en esta última etapa. El usuario recibe la confirmación de que la transacción se incluyó correctamente en un bloque, con niveles de finalidad que varían según el protocolo. La finalidad cierra el proceso y permite verificar los resultados, como saldos o estados de contratos actualizados.

La cadena de suministro de Ethereum

Ethereum busca ser una capa de infraestructura con neutralidad creíble para aplicaciones resistentes a la censura. Su mecanismo de cadena de suministro evolucionó de forma significativa. Al principio operaba con prueba de trabajo (PoW), y los mineros controlaban la inclusión y el orden de las transacciones de Ethereum. Esto propició las subastas de gas prioritario (PGA), donde los buscadores competían por espacio de bloque, lo que saturaba el mempool y generaba un uso ineficiente de la cadena. Flashbots Auction, un relé externo al protocolo para paquetes de MEV, mitigó algunos efectos centralizadores de MEV al trasladar sus mercados fuera de la cadena, aunque dependía de la honestidad tanto del operador del relé como de los mineros.

Con la transición a la prueba de participación (PoS), la producción de bloques de Ethereum pasó a los validadores con participación en staking. Esto introdujo nuevas dinámicas y posibles problemas de centralización. Bajo PoS, las economías de escala en la extracción de MEV podrían centralizar la participación y amenazar la resistencia a la censura de Ethereum.

Para resolver las inquietudes sobre la centralización de la participación, Flashbots introdujo la separación entre proponente y constructor (PBS). Al principio se implementó como MEV-Boost, un nuevo régimen de producción de bloques. En este sistema, los buscadores envían paquetes a los constructores de bloques, quienes crean bloques y presentan ofertas al proponente mediante relés de bloques. MEV-Boost traslada las fuerzas centralizadoras a la capa de construcción de bloques, lo que exige confiar en constructores y relés. En diciembre de 2023, más del 93 % de los bloques de Ethereum eran propuestos por validadores que ejecutaban MEV-Boost.

Sin embargo, MEV-Boost y PBS tienen sus propios problemas. El relé de MEV-Boost operado por Flashbots impone el cumplimiento de la OFAC, un equilibrio indeseable para un sistema justo y sin permisos. La centralización de los relés genera riesgos de censura y comportamiento deshonesto, pues estos se convierten en intermediarios críticos entre constructores y validadores. También existe una gran dependencia de software externo al protocolo, como MEV-Boost. Esto aumenta la vulnerabilidad de Ethereum a vulneraciones y ataques, como demuestra el ataque low-carb-crusader. Hay debates en curso para integrar PBS en el protocolo (ePBS) principal de Ethereum, aprovechando gran parte del trabajo financiado por Flashbots. La centralización de los constructores también preocupa: unos pocos dominan el mercado y podrían censurar e influir en la red. Nuevas soluciones como SUAVE buscan mitigar estas inquietudes.

La cadena de suministro de Solana

Lanzada en 2020, Solana es una L1 independiente que introdujo numerosos avances para resolver el problema de escalabilidad en la capa base sin soluciones adicionales de terceros como las L2. El firme enfoque de Solana en permitir que las aplicaciones “compartan estado” facilita una componibilidad nativa entre ellas. Esto requiere un trabajo mínimo de los desarrolladores y evita operaciones complejas adicionales para los usuarios o supuestos de confianza como los que implican los puentes.

En Solana, una transacción consta de tres componentes principales: un conjunto de instrucciones que define sus operaciones, una lista de cuentas con los permisos asociados con las que interactuará y las firmas necesarias para autenticarla. Cuando el usuario confirma la transacción, esta se envía a un servidor RPC de Solana, que la reenvía al líder actual de la red encargado de producir el bloque. Este sistema se conoce como Gulf Stream, una de las ocho innovaciones únicas que ofrece Solana.

Al recibirla, el líder valida la transacción y programa su ejecución. El modelo de ejecución paralela de Solana permite procesar varias transacciones al mismo tiempo, lo que habilita el paralelismo y los “mercados locales de comisiones”. Esto se logra mediante un programador multihilo que pone las transacciones en cola según las comisiones de prioridad y el tiempo.

Después de ejecutarla, el líder registra la transacción en el libro contable y la distribuye por la red. Su estado se actualiza por etapas: pasa de ejecutada a “confirmada” cuando obtiene suficientes votos de consenso y, por último, a “finalizada” cuando se construye de forma segura sobre ella la cantidad requerida de bloques adicionales (31 o más).

A diferencia de Ethereum, que en la práctica ofrece garantías mucho más sólidas para ordenar transacciones según las comisiones, Solana no usa un orden determinista. Aunque las transacciones que ofrecen mayores comisiones de prioridad suelen tener más probabilidades de ocupar posiciones superiores en un bloque, y los estados con alta competencia suelen exigir comisiones mayores, este resultado no está garantizado. La probabilidad depende de la naturaleza no determinista del algoritmo de programación predeterminado de Solana, que determina la inclusión y posición de cada transacción en un bloque. Esto incentiva la actividad externa al protocolo, incluidos acuerdos directos entre buscadores y validadores, lo que genera externalidades negativas para el usuario promedio.

Sin duda, MEV en Ethereum es un mercado mucho mayor: desde The Merge se extrajeron más de $750 millones (373,701 ETH). Por ello, se dedicaron más tiempo y recursos a MEV, que ahora se comprende e investiga mucho mejor mediante mecanismos compatibles con los incentivos.

Esta es una de las diferencias filosóficas fundamentales entre Ethereum y Solana, y se manifiesta en la asignación de recursos y la cultura de cada ecosistema. Ethereum invierte mucho en investigar y diseñar mecanismos compatibles con los incentivos, como PBS, con debates en curso sobre ePBS. En cambio, el protocolo central de Solana está diseñado específicamente para sincronizar el estado global y delega en equipos del ecosistema como Jito los servicios y garantías especializados de ordenamiento. Anatoly (CEO de Solana Labs) expresa con claridad su opinión de que el estado actual de Solana ofrece un equilibrio (temporal) mejor para el usuario promedio.

Experiencia del usuario (UX) en L1

Desde la perspectiva del usuario, enviar una transacción a una blockchain de capa 1 como Ethereum o Solana es una de las acciones más sencillas del ecosistema cripto. Por lo general, comprende los siguientes pasos:

1. Configurar una billetera

Primero, el usuario debe descargar una billetera. Puede ser una billetera de software como MetaMask, una aplicación móvil o una billetera de hardware para obtener mayor seguridad.

2. Adquirir el token nativo de la L1

Asegúrate de que tu billetera tenga suficientes ETH/SOL para cubrir la transacción y las comisiones de gas. Puedes comprar ETH en distintos exchanges centralizados. Los equipos y protocolos trabajan en la abstracción de cuentas. Una de sus funciones es permitir el pago del gas con cualquier token, no solo con el token nativo de esa L1. Ethereum implementa esta función mediante EIP-4337. Solana tiene abstracción de cuentas nativa integrada en el protocolo y un relé de transacciones sin gas llamado Octane.

3. Introducir los detalles de la transacción

Abre tu billetera y elige la opción para enviar ETH o tokens. Introduce la dirección de Ethereum del destinatario, la cantidad de ETH o tokens que quieres enviar y cualquier dato adicional necesario para interactuar con contratos inteligentes. Si interactúas con una aplicación, el desarrollador suele preparar la transacción por ti.

4. Definir el precio y el límite del gas

La billetera los establecerá automáticamente o te permitirá elegirlos. La implementación exacta del gas variará según la L1 con la que interactúes.

5. Firmar y enviar

Firma la transacción con tu billetera. Este proceso varía según la billetera. A continuación, tu billetera transmitirá la transacción a la red, normalmente mediante un nodo RPC.

6. Confirmación

La transacción queda confirmada cuando se incluye en un bloque y se añade a la blockchain. La mayoría de las billeteras te avisarán cuando se complete. También puedes seguirla con un explorador de blockchain como Etherscan o Solscan.

Experiencia del usuario (UX) en L2

Interactuar con una L2 presenta diferencias claras en la experiencia del usuario. Así se incorporaría un usuario nuevo a Optimism, una de las mayores L2 de Ethereum:

1. Descargar una billetera

Si no tienes una, descarga y configura una billetera. Los usuarios suelen utilizar la misma billetera en distintos ecosistemas EVM, como Metamask.

2. Añadir la red Optimism

3. Depositar ETH en Optimism

• En las L2 grandes, a menudo puedes hacerlo directamente desde la billetera.
• También puedes visitar el puente oficial de Optimism.
• Elige la cantidad de ETH que quieres transferir mediante el puente a Optimism y confirma la transacción.

4. Cambiar a la red Optimism en tu billetera

Abre tu billetera y selecciona "Optimism" en el menú desplegable de redes.

5. Interactuar con aplicaciones e interfaces compatibles con Optimism

Elige “Optimism” en las aplicaciones compatibles con la red Optimism.

Las L2 han logrado avances en la experiencia del usuario, sobre todo en torno a los activos nativos y la incorporación. Circle, que opera USDC, ofrece versiones nativas de USDC en la mayoría de las L2 principales. Esto elimina el riesgo adicional de contraparte que suele acompañar a los puentes y tokens envueltos. Además, la ventaja de distribución de Coinbase permitió integraciones estrechas entre su plataforma y Base, una L2 de Ethereum cuyo único operador del secuenciador es Coinbase.

Componentes de L2

Después de transferir fondos mediante un puente a una L2, un proceso que puede ser poco claro y complicado según la L2, la experiencia de realizar transacciones suele parecerse a la de una L1. Antes, las L2 utilizaban principalmente Ethereum para distintos aspectos de la pila blockchain. Hoy, muchas se orientan hacia un enfoque “modular”. Este enfoque permite combinar distintos ecosistemas e infraestructuras y separar los componentes clave de una L2: ejecución, liquidación y disponibilidad de datos. Antes, las L2 usaban Ethereum para todo salvo la ejecución, pero esto cambia rápidamente con las nuevas soluciones de liquidación y disponibilidad de datos. En cambio, las L1 ofrecen todos estos componentes de manera integrada y definida, sin que los desarrolladores puedan elegir la arquitectura deseada sin la aprobación de la gobernanza.

Ejecución

El objetivo de la ejecución es aplicar una función de transición de estado al estado previo para producir el estado posterior. Se utilizan distintas máquinas virtuales (VM), como Ethereum Virtual Machine (EVM), Sealevel de Solana (SVM) y otras como MoveVM y FuelVM, que sirven como estándares para regir estas transiciones de estado. Cada VM ofrece funciones únicas que afectan la compatibilidad, disponibilidad de herramientas para desarrolladores y eficiencia al procesar transacciones. Estas crean el entorno donde se ejecutan contratos inteligentes y protocolos.

Los desarrolladores de aplicaciones despliegan código, se producen transacciones y los usuarios interactúan con el estado de la blockchain en la capa de ejecución. Esta capa está diseñada para procesar transacciones rápidamente y delegar las responsabilidades de seguridad y disponibilidad de datos en otras capas especializadas.

No es necesario que la máquina virtual de la L2 coincida con la de la L1. Aunque históricamente este solía ser el caso —la mayoría de las L2 son rollups EVM o compatibles con EVM—, más equipos exploran este espacio de diseño con distintas máquinas virtuales que se “liquidan” en Ethereum (Eclipse, Movement Labs).

Liquidación

En este punto, muchos consideran que la palabra “liquidación” es un término sobrecargado. Para comprenderla, es importante distinguir entre la perspectiva del “rollup” y la del “puente”. Los puentes suelen aplicar un proceso de finalización de una semana, pero el puente no es el rollup. Desde la perspectiva del rollup, la finalización ocurre después de verificar la transición de estado y publicar los datos relevantes en una capa de disponibilidad de datos.

Las capas de liquidación cumplen varias funciones clave para los rollups:

• Verificación y gestión de disputas: Funcionan como plataformas donde los rollups pueden publicar sus pruebas para que se validen de forma externa. Esto resulta crucial para los rollups optimistas que dependen de pruebas de fraude interactivas.
• Centro de puentes: Al funcionar como punto central, las capas de liquidación permiten interconectar rollups y eliminan la necesidad de crear puentes individuales entre cada uno.
• Fuente de liquidez: Todos los rollups asociados pueden acceder a la liquidez presente en la capa de liquidación, lo que facilita transacciones e interacciones más fluidas.

Como se mencionó, Ethereum tiene los activos más interesantes y nominalmente valiosos del ecosistema cripto: las personas quieren interactuar con su estado. Ethereum se utiliza como una “capa de liquidación” porque los usuarios muestran una fuerte preferencia por interactuar con un puente integrado en el protocolo hacia una cadena separada, es decir, la L2 de Ethereum que utilizan. El mercado no ha considerado del mismo modo los puentes entre L1, probablemente debido a vulneraciones anteriores y una experiencia del usuario más compleja. Los puentes entre L1 y L2 a menudo pueden integrarse estrechamente en una sola billetera. La experiencia mejora con rapidez gracias a billeteras como Phantom, compatible con Ethereum y Solana, y al lanzamiento de Snaps por parte de Metamask. En términos más formales, los usuarios se sienten cómodos al interactuar con el puente integrado en el protocolo que define un rollup determinado.

El comportamiento de los usuarios cambia rápidamente. Wormhole movió más de $500 millones en volumen durante los últimos 30 días, lo que reduce la distancia frente al volumen de $825 millones procesado por el puente de Optimism en ese mismo periodo.

Puede argumentarse que los puentes L1-L1 han sufrido por la dependencia de la trayectoria, con grandes vulneraciones como el ataque a Wormhole a principios de 2022. Aunque compartir DA habilita supuestos de confianza técnicos únicos, las implementaciones reales de puentes L1-L2 y L1-L1 suelen estar protegidas mediante una multifirma.

La conclusión principal es que los rollups “se liquidan en Ethereum” —o, con mayor precisión, finalizan un puente integrado en el protocolo hacia Ethereum— para acceder al estado de Ethereum con el objetivo explícito de obtener usuarios y liquidez. La liquidación en sí no es rentable para Ethereum, pues rollups como Optimism pagan menos de $50 diarios en ETH a Ethereum por liquidarla. Más del 80 % de los costos de los rollups se destina a publicar datos en los bloques de la L1 de Ethereum como calldata. Por eso hoy existe tanta competencia entre las soluciones de disponibilidad de datos. En total, las L2 representan aproximadamente el ~6 % de las comisiones de la L1 de Ethereum al usarla para la disponibilidad de datos.

Disponibilidad de datos (DA)

La disponibilidad de datos en las blockchains garantiza que todos los datos de un bloque se publiquen y estén disponibles para la red. Este concepto es crucial para el funcionamiento y la seguridad de las blockchains, especialmente al aumentar su escala. Por lo general, un bloque consta de un encabezado y los datos de las transacciones. Los nodos completos descargan y validan cada transacción. Los clientes ligeros requieren menos recursos, se basan solo en el encabezado del bloque y suponen que las transacciones son válidas. El problema de disponibilidad de datos surge cuando un productor publica el encabezado de un bloque, pero retiene parte o la totalidad de los datos de las transacciones.

Aunque todavía no han ocurrido, los ataques de retención de datos amenazan a las redes blockchain. En uno de estos ataques, un productor de bloques malicioso retiene deliberadamente parte de los datos de las transacciones de un bloque nuevo. Esto impide que otros participantes de la red validen las transacciones del bloque. Las consecuencias pueden ir desde interrupciones de la red hasta problemas más graves, como permitir transacciones fraudulentas. La gravedad y el impacto de estos ataques varían según la estructura de la blockchain —capa 1 o capa 2— y según si la disponibilidad de datos se administra dentro o fuera de la cadena. El riesgo subraya la importancia de contar con mecanismos sólidos que garanticen la disponibilidad de datos y estrategias eficaces para mitigar estos ataques.

Para resolver el problema de disponibilidad de datos, pueden usarse métodos como hacer que todos los nodos completos descarguen todos los datos, lo que puede consumir muchos recursos, o enfoques innovadores como las pruebas y el muestreo de disponibilidad de datos (DAS). Estas pruebas aplican técnicas como la codificación de borrado, que permite verificar la disponibilidad al descargar solo una pequeña parte del bloque.

Un verdadero “rollup de Ethereum”, según la terminología más actual, debe usar Ethereum para la disponibilidad de datos. Esto significa que, para considerarse un rollup, debe publicar los datos de las transacciones en la L1 de Ethereum como calldata. Ethereum trabaja actualmente en implementar EIP-4844, que creará un mercado separado para el espacio de blobs —los datos de las transacciones— y permitirá publicar blobs de datos a un precio aún menor. Incluso cuando 4844 esté disponible, solo aumentará la disponibilidad de datos por un factor de ~7, lo que equivale a unas 100 TPS (transacciones por segundo) entre todos los rollups. Como referencia, la demanda de espacio de bloque de Solana ronda las 500 TPS y demostró capacidad para manejar más de 2000 TPS. Además, Solana está diseñada para escalar con los avances de hardware (ley de Moore) y software como Firedancer.

Aunque la disponibilidad de datos puede presentar pequeños efectos de red, es probable que la competencia reduzca el precio de publicar datos en una solución de disponibilidad de datos hasta acercarlo mucho al costo operativo marginal.

La DA garantiza que todos los datos necesarios de las transacciones estén disponibles para reconstruir el estado de una L2 durante un periodo predefinido. A corto plazo, los validiums y volitions utilizan capas de disponibilidad de datos separadas. La hoja de ruta a largo plazo de Ethereum incluye una solución mejorada de disponibilidad de datos mediante actualizaciones como EIP-4844. Se espera que otras soluciones de disponibilidad de datos —por ejemplo, Polygon Avail, Celestia y EigenDA— desempeñen papeles importantes y exploren diferentes diseños de DA. Sin embargo, es importante señalar que estas soluciones todavía no están disponibles, salvo Celestia, que acaba de lanzar su red principal, aunque ningún rollup publica datos en ella. Todas se basan en sistemas novedosos y todavía no demostraron que puedan operar a escala en producción. Además, presentan un amplio espectro de supuestos únicos de seguridad y confianza. Estas soluciones ofrecen una alternativa provisional hasta que la capa integral de disponibilidad de datos de Ethereum esté operativa y podrían demostrar efectos de red incluso después de su integración en Ethereum.

Ciclo de vida de una transacción L2

El ciclo de vida de una transacción en Arbitrum, un protocolo de capa 2, abarca varias etapas desde su inicio hasta su confirmación y finalización:

1. El secuenciador recibe la transacción

Las transacciones comienzan en el secuenciador. Este las recibe directamente o fuera de la cadena en el caso de las transacciones L2, o desde la L1 mediante la bandeja de entrada diferida para los depósitos.

2. El secuenciador ordena la transacción fuera de la cadena

El secuenciador ordena la transacción en su bandeja de entrada fuera de la cadena y la ejecuta mediante la VM Arbitrum Nitro, lo que proporciona un recibo "instantáneo" al cliente. En esta fase, la finalidad depende de confiar en el secuenciador.

3. El secuenciador publica la transacción en un lote dentro de la cadena

El secuenciador publica lotes de transacciones L2 en la L1 a intervalos regulares e incluye los datos relevantes como calldata. Si no incluye una transacción, el cliente puede forzar su inclusión después de un retraso, es decir, mediante inclusión forzada. En esta etapa, si existe al menos un validador activo de Arbitrum que se comporte correctamente, la finalidad de la transacción equivale a la de una transacción de Ethereum.

4. El validador afirma un bloque del rollup (RBlock) que incluye la transacción

Los validadores afirman el estado de la cadena L2 en la L1 a intervalos regulares. Las afirmaciones de RBlock incluyen declaraciones sobre el estado de la bandeja de salida para los mensajes de L2 a L1. Si se impugna: En caso de disputa, los validadores participan en un proceso de verificación detallado hasta una sola operación, arbitrado por contratos en la L1.‍

5. El RBlock se confirma en la L1

Después de resolver las disputas y transcurrir un periodo suficiente, el RBlock se confirma en la L1 y actualiza la raíz de la bandeja de salida.

Este proceso garantiza que, una vez confirmada una transacción L1 que registra un lote, la transacción L2 que contiene tenga el mismo nivel de finalidad que una transacción normal de Ethereum. Si incluye mensajes de L2 a L1, estos solo pueden ejecutarse en la L1 después de confirmar el RBlock.

Como los rollups existen fuera de Ethereum —lo que no debe confundirse con el hecho de que muchos rollups actuales se basan en EVM o son equivalentes a EVM—, hay consideraciones y participantes adicionales en la cadena de suministro de las transacciones. Estas son las características de Arbitrum y Optimism, los rollups dominantes en Ethereum hoy:

• Secuenciador centralizado: Arbitrum y Optimism, los mayores rollups optimistas de Ethereum, operan actualmente con un único secuenciador centralizado. Este secuenciador se encarga de ordenar todas las transacciones. Los planes futuros contemplan descentralizar esta función, posiblemente mediante nodos L2 elegidos por la comunidad, pero los detalles y plazos siguen sin estar claros. Los usuarios confían en que el secuenciador no venderá el flujo de órdenes, reordenará las transacciones ni extraerá MEV de otra forma. Las pruebas de fraude están en la hoja de ruta, pero las impugnaciones sin permisos todavía no están disponibles.
• Supuesto de confianza: En esta etapa, la finalidad depende de confiar en el secuenciador. Su función se limita a ordenar o retrasar transacciones, no a modificarlas. Arbitrum permite forzar la inclusión de transacciones retrasadas más de 24 horas, mientras que Optimism incluye automáticamente las transacciones L1 en el siguiente bloque L2 disponible.
• Reorganizaciones de L1: Si ocurre una reorganización de L1, no existe una política explícitamente detallada para continuar y gestionar los bloques L2. Esto genera cierta incertidumbre sobre la finalidad de las transacciones durante las reorganizaciones de L1.
• Finalidad: Los secuenciadores agrupan transacciones L2 y las publican en Ethereum como calldata. Así alcanzan una “finalidad fuerte” equivalente a la del bloque de Ethereum donde se incluyen. La raíz del árbol de estado de la L2, que representa el estado más reciente del rollup, se actualiza después en la L1 para garantizar cambios de estado irreversibles.
• Periodo de impugnación y retiro: Los validadores de Arbitrum pueden impugnar las raíces de estado e iniciar un proceso de resolución de disputas. Si un compromiso de estado no se impugna durante el periodo designado, se vuelve definitivo. Después del periodo de impugnación, se permiten retiros de L2 a L1 basados en el estado final.
• Puentes: Los protocolos de puentes consideran distintos niveles de finalidad, desde recibos instantáneos con “finalidad débil” hasta calldata agrupada con “finalidad fuerte”. Los puentes pueden optar por mensajes más rápidos según las necesidades del cliente o cumplir estándares de finalidad más estrictos, dependiendo del tipo de transacción y la evaluación del riesgo.

Dónde tienen sentido las L2

Las L2 son sistemas con estado. Cada L2 adicional fragmenta el estado entre las distintas L2. Aunque se sacrifica la componibilidad atómica (que podría estar sobrevalorada o no), implementar en una L2 tiene sentido para algunas aplicaciones. Además, elegir la L2 correcta es muy importante, incluso si se ejecuta en un entorno popular como la EVM. Las distintas L2 ofrecen experiencias de usuario, integraciones y distribuciones muy diferentes.

Sin entrar en demasiados detalles técnicos, las L2 pueden dividirse en términos generales en rollups específicos para aplicaciones y rollups de propósito general.

Rollups específicos para aplicaciones

A diferencia de las L1 y otras L2 mencionadas anteriormente, los rollups específicos para aplicaciones no comparten espacio de bloques con otras aplicaciones. En cambio, son blockchains dedicadas a una aplicación específica (o a un conjunto de aplicaciones). Por ello, eres responsable de operar toda la infraestructura correspondiente.

Aunque algunos equipos están integrados verticalmente y operan su propia infraestructura de forma efectiva (dydx), esto supone un enorme desafío de ingeniería y, por lo general, solo lo logran equipos que ya han alcanzado el ajuste entre producto y mercado (PMF). En el caso de dydx, cuenta con ajuste entre producto y mercado, una comunidad sólida y recursos suficientes para hacerlo (después de alcanzar el PMF en Ethereum y, posteriormente, en una L2 de Ethereum). Otros proyectos, como Maker, exploran diseños como una cadena de aplicaciones basada en SVM. En la práctica, la mayoría de los equipos no opera su propio hardware. En su lugar, depende de proveedores de rollup como servicio (RaaS) que buscan cubrir esta necesidad, como Caldera y Conduit.

Aún no está claro si las cadenas específicas para aplicaciones podrán generar suficientes ingresos para ser rentables a largo plazo. En estos casos, es importante comprender el riesgo de contraparte y la estructura de costos de los proveedores de RaaS. Estos suelen cobrar una tarifa fija (a menudo entre $5,000 y $100,000, según el tamaño de la aplicación) y un porcentaje de las ganancias del secuenciador. La mayoría de los proveedores de RaaS utiliza estándares ampliamente aceptados, como OP Stack, para evitar la “dependencia de un proveedor”. Esto significa que, incluso si el proveedor de RaaS quiebra, aún puedes operar tu propio hardware, siempre que logres superar la interrupción temporal de disponibilidad.

Como los videojuegos son un caso de uso más especializado, se desarrollan activamente implementaciones y protocolos novedosos, como World Engine de Argus. El 5 de diciembre, Dark Frontiers se lanzó como un fragmento de ejecución sobre la L2 EVM de Argus para juegos completamente on-chain, a diferencia de otros juegos on-chain actuales que solo publican elementos simples del juego en la cadena. Aunque todavía está por verse, parece situarse entre los rollups específicos para aplicaciones y los rollups de propósito general.

Rollups de propósito general

Al ser entornos aislados con menos capital económico en juego, los rollups tienen ciertos incentivos para experimentar con determinadas capas del stack, como los niveles de ejecución y consenso, a fin de ofrecer un producto diferenciado. Sin embargo, la mayoría de los rollups son versiones listas para usar de VM existentes (con la excepción de Fuel). Esto se debe a que tienen incentivos para facilitar al máximo que las aplicaciones existentes se implementen en su L2. Como resultado, los equipos que innovan en los niveles de ejecución y consenso tienden a lanzar su propia L1, como Monad.

Es posible que pronto haya más experimentación en la capa de ejecución, ya que la cantidad de rollups supera ampliamente un equilibrio razonable, sobre todo entre los que tienen dificultades para atraer usuarios y liquidez.

Estado actual de los rollups de propósito general

Los rollups de propósito general como Arbitrum, Optimism y Base han demostrado fuertes efectos de red y han atraído numerosas aplicaciones existentes y nuevas para lanzarse en las L2, como GMX y friend.tech. La presencia de los activos nativos y el estado de Ethereum en estas L2 —que suelen usar Ethereum para denominar su token de gas— garantiza que los usuarios y desarrolladores tengan acceso a un ecosistema sólido y maduro. Este acceso es esencial para las aplicaciones que buscan liquidez y compatibilidad con protocolos y activos existentes basados en Ethereum. En cuanto a la experiencia de usuario, plataformas como Coinbase han integrado una cartera nativa y soporte de pagos para Base (donde opera el único secuenciador), lo que permite una interacción fluida y fácil de usar.

Al evaluar distintas L2, es importante considerar entornos de ejecución alternativos para la implementación, la liquidez y la propia infraestructura de la L2. Factores como la estructura de costos de la disponibilidad de datos, los posibles cambios futuros en las tarifas de red y la evolución del panorama de proveedores de infraestructura deben orientar el proceso de decisión. Los desarrolladores de aplicaciones deben comprender la estructura de costos actual para los usuarios y hacer proyecciones razonables sobre el futuro según distintos factores, en especial el costo de la disponibilidad de datos. Para los desarrolladores que consideran implementar en una L2, es fundamental comprender los matices de estos sistemas y prestar especial atención al entorno de ejecución elegido y a las oportunidades de implementación alternativas.

Las investigaciones novedosas lideradas por la Ethereum Foundation, como los “rollups basados” secuenciados por la L1, harán que los rollups sigan mejorando en disponibilidad, descentralización y experiencia de usuario. Los secuenciadores descentralizados —o al menos una rotación entre varios secuenciadores para garantizar la disponibilidad— aún están en fase de investigación, pero ofrecen avances prometedores para garantizar la fiabilidad y reducir el riesgo actual asociado a los secuenciadores. Hoy, los usuarios confían en que el secuenciador operado por el equipo central de la L2 ordene las transacciones de forma justa y no extraiga MEV de forma maliciosa reordenándolas. En caso de censura por parte del secuenciador, los usuarios también pueden enviar transacciones directamente a la L1 mediante la inclusión forzada.

Por otro lado, los rollups actuales carecen de algunas funciones clave que se están desarrollando activamente según sus hojas de ruta. Por ejemplo, ninguno de los principales rollups optimistas ofrece pruebas de fraude sin permisos y, a menudo, están restringidos mediante contratos actualizables controlados por firmas múltiples. Además, muchos rollups carecen de mecanismos de escape para que los usuarios retiren fondos ante un secuenciador malicioso.

El estado final de los rollups de propósito general

Un posible resultado final para los rollups de propósito general incluye un secuenciador “potente” (o un conjunto de ellos). En un mundo donde Ethereum conserva su posición como la cadena con el estado más interesante y los usuarios siguen prefiriendo claramente los puentes de L1 a L2, una o varias L2 de rollup de propósito general pueden ofrecer importantes ventajas de ejecución y una experiencia de usuario mucho mejor. 

En la práctica, la L1 solo existiría para ofrecer las propiedades que necesita el rollup. Esto eliminaría el riesgo de reorganización de la L1 para la L2 y permitiría que la L2 se optimizara según las dimensiones que importan a los usuarios finales: la latencia y la actualización del estado con la mayor eficiencia posible, normalmente en forma de mejores precios. Ethereum —la L1 elegida— aún desempeña un papel porque el consenso social sigue atribuyendo valor al estado de Ethereum por razones meméticas (partes implicadas con una descentralización creíble, lanzamiento justo, etc.). La L2 existe como una entidad externa a la L1.

Los rollups presentarán las siguientes funciones y propiedades:

• Innovación sin permisos – cualquiera puede crear e implementar nuevas aplicaciones
• Resistencia a la censura – mediante la inclusión forzada en la L1
• Disponibilidad de datos – directamente en la L1 o en una capa de DA independiente
• Validez – pruebas de fraude o pruebas zk
• Entorno de ejecución paralelizado – las transacciones se procesan con una eficiencia extrema

En este estado final, hay unos pocos rollups (¿2?) con una cantidad significativa de usuarios y volumen. La aplicación marginal decide implementarse en este rollup porque el acceso masivo a los usuarios compensa el costo de compartir espacio de bloques (amortizado hasta acercarse lo máximo posible a cero). Las preferencias reveladas de los usuarios indican que la máxima prioridad es una UX lo más sencilla posible. Si alguna vez llegamos a este escenario, las criptomonedas habrán reinventado las finanzas tradicionales con varias mejoras clave: innovación sin permisos, resistencia a la censura, ausencia de custodia y transparencia. Solo un pequeño grupo de actores tiene acceso de escritura a los mercados financieros tradicionales. NYSE y otras bolsas son mercados estrictamente regulados y sujetos a permisos que pueden censurar a personas según lo dicten las leyes y regulaciones.

En este escenario, la latencia y la coubicación con los secuenciadores seguirían existiendo, al igual que ocurre con los servidores de libros de órdenes en las finanzas tradicionales. Actualmente, el acceso con permisos determinado por la política y la dependencia de la trayectoria histórica define qué entidades tienen derecho a ubicarse junto a los servidores de NYSE. Las décadas de experiencia de Citadel en optimizar infraestructura y algoritmos para ofrecer mejores precios a los usuarios finales seguirían siendo relevantes en un entorno sin permisos. En este estado final de los rollups, las personas y los equipos competirían contra cualquier otra persona talentosa del mundo únicamente por su rendimiento, lo que daría como resultado mejores precios y experiencias para los usuarios finales.

Aunque todo esto suena bien en teoría, el estado actual de las L2 presenta una realidad muy distinta. El equipo central no solo opera los únicos secuenciadores —un único punto de fallo para la disponibilidad—, sino que además suele restringir las acciones más importantes, ya sea el contrato del puente o las pruebas de fraude con permisos. Aunque muchas L2 tienen previsto descentralizarse y eliminar la firma múltiple, esa no es la situación actual.

Dónde tienen sentido las L1

El concepto de estado compartido en blockchains de capa 1, como Solana y Ethereum, permite la componibilidad sin permisos. Esto significa que las aplicaciones pueden interactuar entre sí sin necesidad de confianza y de manera segura. Una forma de aprovecharlo es mediante estrategias de marketing como los airdrops dirigidos. Por ejemplo, al aprovechar el estado compartido, un proyecto puede identificar y recompensar a comunidades específicas de NFT, lo que permite crear mecanismos de recompensas muy específicos y eficaces. Pyth, un oráculo multicadena de datos, recientemente hizo un airdrop de $PYTH en Solana a cualquiera que hubiera interactuado con su protocolo en más de 40 blockchains. Al analizar los patrones de propiedad y la participación de las comunidades dentro de la blockchain, los proyectos pueden adaptar sus recompensas —como tokens exclusivos o acceso a nuevos servicios— para incentivar e interactuar con segmentos precisos de la comunidad blockchain. Así crean iniciativas de marketing más relevantes y efectivas.

El estado compartido hace posibles de forma única estas atribuciones on-chain para recompensas y acciones. Jupiter, un agregador unificado de trading que garantiza a los usuarios los mejores precios posibles, es un ejemplo de una aplicación que solo puede existir en una cadena con estado compartido como Solana.

Junto con DeFi, los pagos son uno de los casos de uso más importantes de las criptomonedas, ya que permiten enviar cantidades arbitrarias de valor sin intermediarios abusivos como Western Union. Los pagos abarcan tanto transacciones entre pares, como Venmo, como transacciones de empresas a consumidores, como las compras en línea. Es importante que los pagos sean tan baratos y rápidos que los usuarios no tengan que considerar los costos de gas al enviar dinero. En Solana, más de la mitad de las transferencias de USDC son inferiores a $5, algo que solo es posible en blockchains con costos de gas extremadamente bajos, como Solana.

Esto permite crear nuevos negocios, como Tiplink, que permite enviar dinero mediante una URL sin configurar una cartera (incluso puedes registrarte con tus credenciales de Google). Shopify se ha integrado con Solana Pay para que los compradores puedan pagar con USDC en Solana. Visa eligió integrarse con Solana para liquidar USDC para los adquirentes de comercios globales Worldpay y Nuvei. Code ha utilizado nonces duraderos para crear un entorno de ejecución seudoasíncrono y desarrollar un sistema de notificaciones de pago extremadamente rápido, con una experiencia de usuario fluida. Aunque algunas personas lo llaman una L2, no tiene pruebas de fraude y está optimizado exclusivamente para mejorar la experiencia del usuario final.

Solana no tiene L2 porque las transacciones ya son muy baratas y separa y asigna precios al estado de forma nativa dentro de cada bloque. Solana se optimizó desde el principio para sincronizar el estado tan rápido como lo permita la física y acercar el costo de una transacción lo máximo posible al costo marginal de operación. En Ethereum, las transacciones son mucho más costosas, en parte debido a que la EVM utiliza un solo hilo. El estado solo puede recibir precios diferenciados cuando se ejecuta otra instancia de la máquina virtual, que es lo que hacen las L2. Solana y otras blockchains con VM paralelas permiten mercados locales de tarifas, donde cada parte del estado tiene tarifas diferentes según el nivel de competencia por ella. Un foco de actividad localizado en el estado puede gestionarse sin aumentar la competencia ni las tarifas en toda la blockchain. En la práctica, esto significa que acuñar NFT o realizar un airdrop genera pocas externalidades para tu aplicación independiente. 

A diferencia de las L2, el estado final de Solana no está en una hoja de ruta: ya está aquí. Aunque Solana recibe mantenimiento y mejoras constantes mediante SIMDs, es un registro de activos funcional y creíblemente neutral que no exige confianza adicional en firmas múltiples, alineación ni sensaciones.

¿Cuál es la mejor solución para mí?

Bueno, depende de lo que quieras optimizar. Como regla general, los desarrolladores de aplicaciones o propietarios de empresas deben dedicar el mínimo tiempo necesario al mantenimiento de la infraestructura blockchain y el máximo tiempo posible a mejorar su producto para crear la mejor experiencia de usuario. La pregunta es: ¿cuánto tiempo es necesario para ti?

Al elegir una cadena específica, debes estudiar cuidadosamente los elementos fundamentales disponibles en ella. Por ejemplo, aplicaciones como Drip han acuñado más de 60 millones de NFT y cuentan con 500,000 coleccionistas.

Lo que quieras optimizar terminará por reducir tus opciones de cadenas. Según el resumen anterior de las distintas L1 y L2, estas son algunas dimensiones que debes considerar:

1. Usuarios on-chain
2. Uso on-chain (si optimizas para una función on-chain específica, como el trading, deberás examinar las cadenas con entornos de tarifas bajas, como Solana, Sui u Optimism. También deberás comprender las ventajas, desventajas y limitaciones técnicas de los tiempos de bloque más cortos, los bloques más grandes, etc.)
3. Tiempo de ejecución
4. Liquidez on-chain
5. Grandes tenedores/liquidez on-chain (por ejemplo, el ecosistema EVM suele tener más liquidez debido a la era anterior de lanzamientos de tokens, pero esto cambia rápidamente)
6. Acceso a comunidades on-chain específicas (artistas, traders, etc.)
7. Disponibilidad de subvenciones y capital de riesgo (los ecosistemas más nuevos tienen más capital para subvenciones, pero menos capital de riesgo)
8. Complejidad técnica y carga de gestión (por ejemplo, Code solo necesita 2 ingenieros para operar su aplicación en Solana, mientras que dydx necesita más de 30 ingenieros e investigadores)
9. Capacidad de programación y soberanía sobre las reglas de la cadena (por ejemplo, reglas particulares de liquidación de operaciones)
10. Acceso a participantes institucionales (por ejemplo, Coinbase en Base, y Visa y Shopify en Solana)
11. Componibilidad con otras aplicaciones del ecosistema (por ejemplo, DeFi y aplicaciones de pagos)

Implementar en determinadas estructuras de rollup puede tener sentido para ciertas aplicaciones que comprendan y aprovechen de forma única las propiedades mencionadas. Para la mayoría de las aplicaciones, Solana ofrece los elementos fundamentales necesarios para alcanzar el éxito. Sus decisiones de diseño únicas le permiten ser rápida, barata y eficiente, y lleva muchos años operando en producción.

Conclusión

Comprender y navegar por el panorama blockchain, en especial al elegir entre plataformas de capa 1 (L1) y capa 2 (L2), requiere una visión detallada de las ventajas y desventajas implicadas. Elegir entre L1 y L2 es más que una decisión técnica: es una estrategia empresarial fundamental que influye en la escalabilidad, la seguridad y la viabilidad general de un proyecto. Además, refactorizar toda una base de código generará más deuda técnica y reducirá tus probabilidades de crear una aplicación exitosa.

No se puede subestimar el papel de la experiencia de usuario en la adopción de blockchain. A medida que la tecnología madura, el enfoque debe orientarse cada vez más a crear interfaces intuitivas, fluidas y fáciles de usar que reduzcan la brecha entre la compleja infraestructura blockchain y el usuario final. Aunque distintas aplicaciones se benefician de diferentes niveles de flexibilidad, la mayoría de los desarrolladores debería elegir una plataforma que les permita dedicar el máximo tiempo posible a crear el mejor producto.

Gracias a Akshay, 0xIchigo y Jon Charbonneau por sus revisiones y comentarios.