Hace un mes, Vibhu, el fundador de DRiP, la principal aplicación de consumo sobre Solana que distribuye NFT gratuitos de los mejores artistas, desató un debate muy necesario con su declaración:

Solana va a tener y necesita tener L2 y/o rollups

Su frustración surgió porque DRiP ha estado perdiendo un valor significativo (~ $ 20K / semana) a la capa base, gracias al aumento de los precios de SOL y la congestión de la red. El aumento de la actividad en Solana conduce a:

• Ventajas: mejora de la liquidez, el capital y los volúmenes de transacciones (gracias a la componibilidad)Desventajas:
• costes de infraestructura elevados, mala experiencia del usuario y congestión

Sin embargo, DRiP, que utiliza principalmente Solana como infraestructura para distribuir millones de NFT semanales de artistas a miles de billeteras, no se beneficia de una alta componibilidad . El crecimiento en el TVL de Solana y la afluencia de capital tiene poco impacto en DRiP, que sufre principalmente de inconvenientes, como altos costos de infraestructura.

Vibhu señala: "La componibilidad tiene rendimientos decrecientes". También señala que los desarrolladores de aplicaciones de Solana están discutiendo en privado su deseo de rollups debido a:

1. Aumento del rendimiento de las transacciones, menos competencia en el espacio de bloques y reducción de las comisiones.
2. Mayor control sobre el valor económico que generan sus negocios.

Enlace de publicación

En los últimos meses, Solana ha experimentado múltiples incidentes de congestión, que van desde lanzamientos aéreos como JUP hasta minería ORE y comercio pico de memecoins. Si bien se podría argumentar que Firedancer puede resolver todos estos problemas, seamos realistas: la línea de tiempo sigue siendo incierta y no puede escalar más allá de 10x por ahora. A pesar de esto, es cierto que entre todas las grandes cadenas que han sido probadas en batalla, Solana se erige como el último monolito verdadero que queda.

¿Debería Solana seguir siendo un monolito o convertirse en modular? ¿Solana también evolucionará como Ethereum con soluciones L2 y L3 fragmentadas, entre otras? ¿Cuál es el panorama actual de appchains y rollups en Solana?

Para abordar estas preguntas y resumir todo el debate, este ensayo explorará todas las posibilidades, discutirá varios proyectos y evaluará sus pros y sus contras.

Este artículo no profundizará en los tecnicismos, sino que adoptará una perspectiva más práctica y orientada al mercado al discutir varios enfoques de escalado para proporcionar una visión general.

Todas las ideas, sin pelusas, además de mucho alfa.

En pocas palabras, discutiremos:

1. Solana y la congestión
2. que hace Solana Modular
3. Solana Appchains - con ejemplos
4. Sollana Layer-2s y Rollups (RollApps) - con ejemplos
5. Infra Powering Rollups y Appchains

Solana y la congestión:

Comencemos abordando el elefante en la habitación: la red Solana ha estado muy congestionada últimamente (ahora casi resuelta) debido a los lanzamientos aéreos, una cantidad sustancial de actividad comercial memecoin, etc., líder a los altos tiempos de ping, un alto porcentaje de transacciones fallidas y un aumento de la tarifas de red debido a tarifas de prioridad más altas. A pesar de todo esto, Solana ha procesado consistentemente alrededor de 1-2k TPS, más que todas las cadenas EVM combinadas. Yo diría que es un buen problema para una cadena de bloques, y también ha puesto a prueba la tesis monolítica de Solana.

La Fundación Solana recientemente publicó un blog instando a los proyectos a tomar medidas inmediatas para mejorar el rendimiento de la red, incluyendo:

• Implementación de tarifas prioritarias: fundamental para evitar retrasos o cancelaciones de transacciones.
• Optimización del uso de la unidad de cómputo de programa (CU): usar solo lo necesario.
• Implementación de calidad de servicio (QoS) ponderada por stake, lo que permite a las aplicaciones priorizar el procesamiento de transacciones de sus usuarios.

Sin embargo, todas estas medidas solo mejoran un poco la finalización de las transacciones y no garantizan una experiencia de usuario fluida en las transacciones. Una solución inmediata a este problema es el tan esperado nuevo Programador de transacciones, cuyo lanzamiento está previsto para finales de abril en la versión 1.18. Se introducirá junto con el programador actual, pero no estará habilitado de forma predeterminada, lo que permitirá a los validadores monitorear el rendimiento del nuevo programador y volver fácilmente al anterior si surge algún problema. Este nuevo programador tiene como objetivo llenar bloques de manera más eficiente y económica, mejorando las ineficiencias del programador anterior. Lea este artículo para obtener más información sobre el @harshpatel_36138/whats-new-with-solana-s-transaction-scheduler-bcf79a7d33f7">new Scheduler.

Anza (una entidad derivada de Solana Labs) ha estado ccontinuamente tratando de resolver el congestión de la red que se ha identificado como problemas relacionados con la implementación de QUIC y el comportamiento del cliente validador Agave (Solana Labs), cuando se le pidió que procesara una gran cantidad de solicitudes.

Enlace de publicación

Mientras que los defensores de la modularidad han abogado firmemente por una "hoja de ruta modular" para Solana, Solana Labs/Anza (el principal responsable del Solana protocolo) sigue centrada en optimizar el rendimiento y la latencia de la capa base. Algunas mejoras potenciales incluyen:

1. Revisión de los mercados de tarifas y aumento de las tarifas base (actualmente establecidas en 5,000 Lamports o 0.000005 SOL).

2. Implementar una tarifa de bloqueo de escritura exponencial para las cuentas, es decir, aumentar gradualmente las tarifas a lo largo del tiempo para desalentar el spam.

3. Optimización de las solicitudes de presupuesto de CU a través de un sistema de penalización.

4. Mejora de la arquitectura general de la red.

Incluso con estas mejoras en el escalado vertical (cadena única), no podemos descartar la posibilidad de que Solana adopte el escalado horizontal (rollups). La realidad es que Solana puede convertirse en un híbrido de ambos: podría servir como una excelente capa base para rollups, con tiempos de bloque de latencia súper baja (~ 400 ms) que beneficiarían significativamente a los rollups, como permitir una confirmación suave súper rápida de los secuenciadores. La mejor parte es que Solana históricamente ha sido rápido para implementar cambios, lo que potencialmente lo convierte en una capa más eficiente para rollups que Ethereum.

Actualización: Anza ha empujado algunos parches que ayudan a aliviar algunos de los congestión de la red en curso, y serán seguidos por más mejoras en la versión 1.18.

Making Solana Modular:

Los esfuerzos para hacer Solana modulares ya han comenzado. Como indica la publicación de Anza DevRel, el validador Solana y la SVM (entorno de ejecución que procesa transacciones y contratos inteligentes/programas) están estrechamente acoplados y mantenidos por Anza (una entidad derivada de Solana Labs). Sin embargo, el cliente validador y el tiempo de ejecución de SVM se separarán en los próximos meses. Esta separación facilitará la bifurcación de la SVM y la creación fácil de 'Solana appchains'.

Para los rollups, el beneficio podría provenir de la optimización de la capa de disponibilidad de datos (DA)/blob de Solana, aunque esto puede suceder en una etapa posterior.

Fuente: Anza DevRel

Joe C (ingeniero de Anza) también dio a conocer los planes para hacer que SVM sea modular, donde la canalización de procesamiento de transacciones se sacará del validador y se colocará en SVM. Esto permitirá a los desarrolladores ejecutar la implementación de SVM y operar independientemente de cualquier validador.

La SVM aislada será un conjunto de módulos totalmente independientes. Cualquier implementación de SVM podría impulsar estos módulos a través de interfaces bien definidas, lo que reduciría aún más las barreras para los proyectos compatibles con SVM al disminuir significativamente la sobrecarga necesaria para diseñar soluciones personalizadas. Los equipos podrían implementar solo los módulos que les interesen, mientras que utilizan implementaciones establecidas para el resto, como las de Agave o Firedancer.

En coro, Solana sería más plug-and-play, haciendo que las appchains y rollups de Solana sean mucho más fáciles.

En términos generales, hay dos direcciones en las que esto puede ir: Layer-2s/Rollups y Appchains. Echaremos un vistazo a ambos, uno por uno.

Solana Appchains:

También conocidas como bifurcaciones SVM, son esencialmente bifurcaciones de la cadena de Solana dedicadas a aplicaciones específicas. Pyth fue el primero Solana appchain, pero el concepto realmente llamó la atención cuando Rune, el fundador de uno de los protocolos de DeFi más grandes, Maker causó un gran revuelo con su propuesta de desarrollar una cadena de aplicaciones Maker (para la gobernanza) basada en la base de código Solana (SVM). Eligió SVM debido a su sólida comunidad de desarrolladores y su superioridad técnica sobre otras máquinas virtuales, con el objetivo de fork la cadena de mayor rendimiento para satisfacer mejor las necesidades de los consumidores. Aunque aún no se ha implementado nada, este movimiento provocó un debate muy necesario sobre las cadenas de aplicaciones de Solana.

A grandes rasgos, puede ser de dos tipos:

1. Sin permiso: cualquiera puede unirse a la red, similar a la red principal actual de Solana.
2. Con permisos: empaquetado como 'Solana Permissioned Environments (SPE)' por la Fundación Solana para instituciones, permite a las entidades crear y mantener su propia instancia de cadena, impulsada por la SVM.

Pyth – The OG Solana Appchain:
En un momento dado, Pyth representaba entre el 10 y el 20% de todas las transacciones en la red principal de Solana. Sin embargo, no requería ninguna componibilidad, por lo que simplemente bifurcaron el código base de Solana. Esto les permitió aprovechar el rápido tiempo del bloque de Solana de 400 ms para actualizaciones de precios de alta frecuencia. Pythnet fue la primera red en adoptar SVM para su cadena de aplicaciones.

La cadena de aplicaciones de Pythnet es una fork de prueba de autoridad de la red principal de Solana, que sirve como una capa base computacional para procesar y agregar datos proporcionados por la red de publicadores de datos de Pyth.

¿Por qué se mudó Pyth?
-No requería alta componibilidad (particularmente para aplicaciones que no eran de Solana) y, por lo tanto, estaba libre de congestión de la red principal.

• Necesitaba un entorno con permisos para publicar datos.
• Reducción de los costes de infraestructura mediante la internalización de las tarifas, que anteriormente se filtraban a la capa base (Solana).

Cube Exchange es otro ejemplo, un CEX híbrido implementado como una cadena de aplicaciones SVM soberana (con un libro completamente off-chain orden y liquidación en su cadena de aplicaciones SVM)

Algunos ejemplos de Solana Appchains podrían ser:

1. DEX de Perp: Al igual que Hyperliquid, los DEX de Perp pueden funcionar como redes L1 separadas. Además, para los casos de uso comercial, se puede personalizar el número de transacciones por bloque o se puede implementar lógica condicional, como integrar la ejecución de un orden de stop-loss directamente en la L1, garantizar que se aplique como una transición de estado o introducir lógica atómica específica de la aplicación.
2. AI y DePIN: Estos pueden presentar una lista controlada de proveedores de servicios como Pyth. Por ejemplo, Akash funciona como un marketplace informático a través de una cadena de aplicaciones de Cosmos.
3. Cadenas de aplicaciones de gobernanza: Validadas por el interés de MakerDAO en una cadena de aplicaciones de SVM, una cadena de aplicaciones de gobernanza soberana puede ser convincente. La gobernanza en las criptomonedas aún está evolucionando, y tener una cadena dedicada a fork puede ser un mecanismo de coordinación útil.
4. Futuras cadenas de aplicaciones empresariales: Las aplicaciones potenciales incluyen fondos (como BlackRock) o sistemas de pago (como Visa o CBDC).
5. Gaming Appchains: Un proyecto de juegos de casino en Solana está considerando su appchain.
6. Bifurcaciones modificadas de Solana: De manera similar a cómo Monad o Sei ofrecen EVM optimizadas (paralelizadas), alguien podría construir una versión más optimizada de Solana. Esta tendencia podría volverse más frecuente en los próximos años, especialmente a medida que la red principal de Solana comience a explorar nuevas arquitecturas de diseño.

Imagining the Solana Appchain Stack:

Si bien establecer una appchain puede ser relativamente sencillo, garantizar la conectividad entre todas las appchains es crucial para la interoperabilidad. Inspirándose en las subredes de Avalanche (conectadas por Avalanche Warp Messaging nativas) y las cadenas de aplicaciones de Cosmos (conectadas por IBC), también Solana podría crear un marco de mensajería nativo para conectar estas cadenas de aplicaciones.

Enlace de publicación

También se podría crear un middleware similar a Cosmos-SDK, ofreciendo una solución llave en mano para crear appchains con soporte incorporado para oráculos (como Pyth o Switchboard), RPC (como Helius) y conectividad de mensajería (como Wormhole), entre otros.

Polygon AggLayer también sería un enfoque interesante, donde los desarrolladores pueden conectar cualquier cadena L1 o L2 a AggLayer, que agrega pruebas ZK de todas las cadenas conectadas.

Es una appchain neta positiva para el ecosistema Solana?

Aunque las appchains no acumulan valor directamente para SOL, ya que no pagarían tarifas en SOL ni usarían SOL como token de gas, a menos que el SOL reapostado se use para la seguridad económica, benefician enormemente al ecosistema SVM. Así como hay "efectos de red EVM", más bifurcaciones y appchains de SVM fortalecerán los efectos de red de SVM. Se aplica la misma lógica que hace que Eclipse (SVM L2 en Ethereum) sea alcista para SVM, a pesar de que es un competidor directo de la red principal de Solana.

Solana Layer-2s:

Solana Las capas 2, o rollups, son cadenas lógicamente separadas que publican datos en la capa de disponibilidad de datos (DA) de su cadena host y reutilizan el mecanismo de consenso de la cadena host. También pueden usar otras capas DA como Celestia, sin embargo, no sigue siendo un verdadero rollup. "RollApp" es un término generalmente utilizado para Rollups específicos de la aplicación (que la mayoría de las aplicaciones de Solana están explorando).

¿Solana Rollups sería lo mismo que Ethereum?
Aparentemente no. Para Solana, los Rollups se abstraerían principalmente para el usuario final. En el frente ideológico, Ethereum rollups fueron de arriba hacia abajo, donde la Fundación Ethereum y los líderes decidieron que la mejor manera de escalar era a través de rollups, y comenzaron a apoyar a varios L2 después del fiasco de CryptoKitties. Mientras que en Solana, la demanda es ascendente, es decir, proviene de desarrolladores de aplicaciones con una adopción significativa por parte de los consumidores. Como resultado, la mayoría de las jugadas roll-up actuales son jugadas de marketing y están más impulsadas por la narrativa que por la demanda de los consumidores. Esta es una diferencia significativa y puede conducir a un futuro diferente para los rollups que lo que vimos en Ethereum.

¿Son Compression = Rollups?

Las L2 escalan las cadenas de bloques de capa base (L1) ejecutando transacciones en la L2, procesando por lotes los datos de la transacción y comprimiéndolos. A continuación, los datos comprimidos se envían a la L1 y se utilizan en la prueba de fraude (rollup optimista) o en la prueba de validez (rollup zk). Este proceso de prueba se conoce como "liquidación". Del mismo modo, la compresión descarga las transacciones de la red principal, lo que reduce la contención por el estado en la capa base. En particular, Grass L2 aprovechará State Compression para su acumulación.

Rollups Landscape on Solana:

Dos 'algo rollapps' están activas actualmente:

1. GetCode:

Una aplicación de pagos con un SDK de micropagos permite a cualquier persona pagar y aceptar pagos al instante y también utiliza un pseudo-rollup para su aplicación. Crea intenciones para todas las transacciones y emplea un secuenciador tipo rollup, que se asienta en Solana después de N intervalos.

El uso de una estructura tipo rollup permite:

1. Flexibilidad: Las intenciones pueden representar varias actividades futuras, no solo transacciones de pago. Además, Solana como cadena también puede ser reemplazada si es necesario.
2. Instantáneo y privado: Dada la suave finalidad del secuenciador, los pagos son instantáneos incluso durante Solana congestión. Si bien las transacciones son visibles on-chain, el valor exacto y la intención permanecen ocultos, lo que garantiza la privacidad del usuario.

2. Rollups eféricos de MagicBlocks

MagicBlocks, una infraestructura de juegos web3, ha desarrollado rollups efímeros (o temporales), especialmente para juegos. Utiliza la estructura de cuentas de SVM y el estado del juego se divide en clústeres. Transfiere temporalmente el estado a una capa auxiliar o al "rollup efímero", una capa dedicada configurable. El rollup efímero funciona como un tiempo de ejecución o rollup de SVM especializado para facilitar el procesamiento de transacciones con un rendimiento elevado.

El uso de una estructura tipo rollup permite:

1. Personalización del tiempo de ejecución especializado para incluir características como transacciones sin gas, tiempos de bloque más rápidos y la incorporación de un mecanismo de ticking (por ejemplo, un sistema integrado de programación de transacciones como clockwork, operado sin cargos).
2. Los desarrolladores implementan programas en la capa base (por ejemplo, Solana) en lugar de en una cadena separada o rollup. Los ER no fragmentan el ecosistema existente y permiten la aceleración de operaciones específicas sin crear un entorno aislado. Esto significa que se puede utilizar toda la infraestructura existente de Solana.

Este enfoque facilita un sistema altamente escalable capaz de lanzar rollups bajo demanda y escalar automáticamente horizontalmente para acomodar a los usuarios que realizan millones de transacciones, sin las compensaciones típicas de las L2 tradicionales. Si bien MagicBlock se centra específicamente en los juegos, este enfoque se puede aplicar a otras aplicaciones como los pagos.

Upcoming Solana Rollups:

1. Grass: Un proyecto DePIN destinado a resolver problemas de datos de IA a través del raspado verificado. Cuando los nodos de Grass raspan la web en busca de datos de entrenamiento de IA, los validadores almacenarán los datos on-chain, rastreando con precisión dónde se originaron los datos y qué nodo fue responsable de extraerlos, recompensándolos proporcionalmente.

Grass requiere 1 millón de solicitudes web por segundo, lo cual es inviable en la red principal de Solana. Por lo tanto, planean hacer pruebas ZK de los datos de origen para todos los conjuntos de datos y agruparlos para su liquidación en Solana L1. Están considerando usar la compresión de estado de otro clúster y establecer raíces en la versión beta de la red principal.

Este desarrollo posicionará a Grass como una capa base para una amplia gama de aplicaciones que solo son posibles sobre Grass (tenga en cuenta que las plataformas y la infraestructura a menudo tienen valoraciones mucho más altas y Grass lanzará el token pronto :P).

1. Zeta: Uno de los DEX de perp más antiguos de Solana que tenía un libro de orden de perp completamente on-chain también está planeando mover su coincidencia off-chain a través del Solana rollup.

Los DEX de Perp tienen un PMF inmediato para rollups, ya que mejoran significativamente la experiencia de usuario. Solo pregúntele a alguien que haya operado en Hyperliquid o Aevo versus Solana perp DEXs, donde debe firmar cada transacción, aparece una billetera y debe esperar ~ 10-20 segundos. Además, los perps no requieren ejecución sincronizada y ofrecen una alta componibilidad con el resto de DeFi, particularmente en el aspecto de coincidencia comercial.

Curiosamente, Armani (cofundador de Backpack) también tuiteó que ahora están tendiendo a L2.

Sonic también está construyendo una cadena SVM modular (Hypergrid) que permitirá a los juegos desplegar sus propias cadenas en Solana. También hay Ethereum rollups basadas en SVM como Eclipse y NitroVM que utilizan SVM como motor de ejecución. Neon funciona como una L2 compatible con EVM en Solana. Además, hay proyectos en fase de idea, como Molecule (una SVM Bitcoin Capa 2).

Sovereign SDK es otro marco similar a node.js, pero para crear rollups. Los usuarios traen su código de Rust y lo convertimos en un rollup Optimistic o ZK que se puede implementar en cualquier cadena de bloques. El código de Rust puede ser la lógica específica de su aplicación o cualquier VM.

Algunas tesis sobre Rollups:

1. Rollups = Estar alineado con SOL:
   El término 'ETH-Aligned', o una mejor palabra para 'ETH Bag Biases', se ha convertido en un meme popular. ¿Por qué crees que Layer 2s y Restaking/EigenLayer se han convertido en la narrativa más candente? Es porque aumentan el 'Moneyness of ETH', con ETH siendo utilizado como el activo principal en todas partes.

El mismo principio se aplica a Solana. La comunidad de Solana se unirá en torno a cualquier solución que impulse sus tenencias de SOL, es así de simple. A medida que el ecosistema de Solana se expanda, la "Moneyness of SOL", una vez pasada por alto, cobrará importancia. Recuerde, la mayoría de los Rollups son de todos modos un "juego de marketing" y brindan una mejor acumulación de valor de token, ya que los mercados aún valoran más la infraestructura que las aplicaciones.

1. Los rollups se sentirán como una extensión de Solana:
   más allá de los beneficios de seguridad (es decir, heredar la seguridad de la capa base), el fácil acceso a los usuarios y activos de Solana será una ventaja significativa. Como señala Jon Charbonneau, Ethereum Rollups como Base, Optimism y Arbitrum se sienten más como extensiones de Ethereum. Los usuarios mantienen las mismas billeteras y direcciones, el token gas nativo es una única versión canónica de ETH, ETH domina DeFi con todos los pares comerciales, las aplicaciones sociales fijan el precio de los NFT en ETH y pagan a los creadores en ETH (por ejemplo, friend.tech), y los depósitos en la L2 son instantáneos, etc.

Del mismo modo, esto sucederá con Solana. Aprendiendo de Ethereum, la mayoría de las Rollapps de Solana no harán que los usuarios sientan que están usando una cadena separada (por ejemplo, Getcode).

1. Solana verá más "RollApps" que "Rollups"
   Solana no tiene un problema de escalado como Ethereum, donde la red principal es simplemente inutilizable debido a las altas tarifas de gas, está altamente optimizada. Sin embargo, algunas aplicaciones que necesitan espacio de bloque dedicado crearán sus rollups. Si bien los Rollups de uso general en Solana no tienen sentido para mí, económicamente sí tienen sentido para los proyectos. Por ejemplo, los usuarios de Base generaron 2 millones de dólares en ingresos para Coinbase en un solo día. Los incentivos para los constructores están muy sesgados hacia la L2. Sin embargo, como se observó, cada rollup de EVM parece ser un roll-up de vainilla, y muchos, como Linea, Scroll o zkSync, se han convertido en cadenas fantasma con solo agricultores que realizan algunas transacciones para lanzamientos aéreos de tokens.

Además, creo que los L2 de propósito general en Solana pueden conducir a los mismos viejos problemas de Ethereum, es decir, rollups centralizados, congestión y fragmentación de liquidez.

1. ¿Por qué algunas aplicaciones querrían pasar a Rollapps/appchain?
   Inicialmente, todas las aplicaciones se iniciarán en el Solana Mainnet, ya que alojar más aplicaciones en una infraestructura compartida reduce significativamente la complejidad de los desarrolladores y los usuarios. Sin embargo, a medida que estas aplicaciones crecen, es posible que busquen:
   • Captura de valor: Es más difícil internalizar el valor en una capa compartida de Solana que no está diseñada con una sola aplicación en mente. La captura MEV puede ser otra opción lucrativa para los DEX.
   • Personalización del espacio de bloques dedicado
   • en casos de uso como:
     • Privacidad: Por ejemplo, Getcode utiliza un secuenciador para facilitar los pagos privados a sus usuarios.
     • Experimentaciones de mercado de tarifas
     • Mempools cifrados para minimizar MEV
     • Libros de órdenes personalizados
2. Sin embargo, no todas las aplicaciones querrán lanzar su propio Rollup, especialmente aquellas que no han alcanzado una cierta velocidad de escape (por ejemplo, suficiente TVL, usuarios, volumen). Lanzar su propia cadena hoy en día implica compensaciones dolorosas e innecesarias (complejidad, costo, peor UX, liquidez fragmentada, etc.), que la mayoría de las aplicaciones, particularmente las que se encuentran en la etapa inicial, no pueden justificar por los beneficios incrementales. Solana sigue siendo el corazón y el alma del desarrollo de SVM, y es probable que se implementen muchas aplicaciones nuevas como resultado.
   Para los creadores de aplicaciones: Solana Mainnet o Appchain o Rollup
   depende completamente. Si no hay una gran necesidad de componibilidad con todas las demás aplicaciones, tomar algunos componentes diferentes off-chain (ya sea appchain o rollup) tiene mucho sentido. Un usuario no debería necesitar saber que está usando un rollup o una cadena de aplicaciones. Grass, Zeta y Getcode abstraen cualquier infraestructura de tipo rollup que estén utilizando para sus usuarios.

En el caso de los casos de uso con permisos y personalización, Token también satisface la mayoría de las necesidades, como la lógica de KYC/transferencia, a la vez que conserva la componencia.
Entonces, ¿DRiP será una L2/appchain?
Actualmente, DRiP utiliza Solana para:

* Billeteras de creación de usuarios (pueden estar en L2 / appchain)
* Distribución de NFT comprimidos (puede ser en L2/appchain)
* Trading de NFT comprimidos (puede ser en L2/appchain, pero los fondos deben ser puenteados)

1. Podemos ver claramente que no hay una gran necesidad de estar en Solana Layer 1, además de la tecnología que L2s / appchains también pueden proporcionar. Dado que el objetivo principal de DRiP siempre han sido los usuarios de web2, puede muy bien incorporarlos directamente a su cadena, lo que le da un control mucho mayor a largo plazo, ya que no perderá todo el valor a la cadena base (Solana). Además, DRiP ha alcanzado la velocidad de escape (la aplicación de consumo más grande en Solana) para ahora pasar a su propia cadena. Una estructura pseudo-rollup como Getcode tiene completamente sentido para DRiP.

Infrastructure Powering Rollups and Appchains:

Si la tesis de rollapp/appchain se expande, los proveedores de infraestructura existentes se beneficiarán enormemente a medida que accedan a nuevos mercados:

1. Los proveedores existentes de Rollup as a Service (RaaS) como Caldera pueden ingresar fácilmente al mercado de SVM a medida que surge la demanda. SVM Ethereum rollups como Eclipse y NitroVM también están observando con interés esta oportunidad. Además, Sovereign Labs ofrece un adaptador de Solana < href="https://x.com/cemozer_/status/1770547488132383160">Sovereign SDK que permite rollups en Solana (aún no está listo para producción). Helius es otra empresa muy adecuada para construir infraestructura para Solana L2, como Mert ha insinuado en múltiples ocasiones.
2. Secuenciadores compartidos como Rome Protocol y la necesidad de clientes ligeros como Tinydancer. Los secuenciadores compartidos pueden ser interesantes para los rollups, ya que permiten actividades como el arbitraje atómico, MEV y el puente sin fisuras, disminuyendo la fragmentación de la liquidez.
3. Carteras como Phantom, Backpack y Solflare. Infraestructura de billetera multi-sig y contratos inteligentes como Squads. Los escuadrones siempre se han posicionado como "La capa definitiva de infraestructura de billetera de contratos inteligentes para Solana y SVM".
4. Replanteamiento SOL: La tesis modular también promueve el replanteo, ya que estos rollups / appchains pueden requerir seguridad compartida SOL y estar más alineados con Solana. Esto conduce a:
   1. Jugadores en etapa inicial como Cambrian, Picaso y Solayer
   2. Jito a través de Stakenet y LST como Validadores de Sanctum:
   3. mayores ingresos

Closing Thoughts: ¿Puede Solana manejar la demanda de todo el mundo?

Definitivamente no. Seamos realistas: incluso considerando la Ley de Moore (que el rendimiento del hardware continuará mejorando, y Solana está optimizado para tales avances de hardware), no es práctico. Creo que todas las transacciones menos críticas (como DRiP enviando NFT) eventualmente se trasladarán a sus propias cadenas, mientras que las transacciones más valiosas permanecerán en la cadena principal, donde la verdadera componibilidad es esencial (por ejemplo, DEX al contado).

Y no, esto no significa que Solana haya perdido en la batalla del monolito y la componibilidad; gestionará los casos que dependen de la componibilidad y la baja latencia mejor que otras cadenas. Y no, Sui / Aptos / Sei / Monad, etc., etc. aún no son mejores, ya que no lo sabemos y aún no se han probado en batalla para la alta actividad real de los usuarios.

A diferencia de Ethereum, la Solana Mainnet no pretende ser la "cadena B2B", sino que fue y será siempre la cadena de consumo. Construir sistemas distribuidos a escala es increíblemente desafiante, y Solana tiene el mejor potencial para convertirse en el libro mayor compartido global para las transacciones más valiosas.

Solana necesita almas gemelas: ¿podrían las Appchains y los Rollups ser su combinación perfecta?

No dudes en ponerte en contacto conmigo en Yash Agarwal (@yashhsm en Twitter) para cualquier sugerencia o si tienes alguna opinión. Si encuentra esto aunque sea un poco perspicaz, por favor compártalo: justifica mis semanas de esfuerzo y atrae más miradas :)

Un agradecimiento especial a Karthik (PepperDEX), Brian Breslow (Dorahacks), Parth (Arana Ventures), Rex (Anza), Het Dagli (Superteam), Kash (Superteam), y Akshay (Superequipo), que revisó y proporcionó información en diferentes etapas del draft.

Disclaimer:

1. Este artículo es una reimpresión de [The Superteam Blog]. Todos los derechos de autor pertenecen al autor original [YASH AGARWA]. Si hay objeciones a esta reimpresión, póngase en contacto con el equipo de Gate Learn, y ellos se encargarán de ello con prontitud.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo 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.