Título original: "¿Solana necesita L2 y cadenas de aplicaciones?"
Autor original: Yash Agarwal
Compilación original: Ladyfinger, BlockBeats
Nota del editor:
Como plataforma de cadena pública de alto rendimiento, Solana enfrenta oportunidades y desafíos de desarrollo sin precedentes. En este artículo, Yash Agarwal ofrece una mirada panorámica y en profundidad a los temas clave del ecosistema de Solana (modularización, cadenas de aplicaciones y paquetes acumulativos) y cómo trabajan juntos para impulsar a Solana hacia un futuro más amplio.
Introducción
Hace un mes, Vibhu, el fundador de DRiP, la principal aplicación de distribución gratuita de NFT en Solana, hizo una declaración que desató una discusión generalizada:
Solana tendrá y necesita tener Capa 2 y Rollup.
Expresó esta opinión porque DRiP está perdiendo alrededor de 20.000 dólares en valor cada semana a medida que aumentan los precios de SOL y la congestión de la red. El aumento de la actividad en la red de Solana ha tenido dos impactos:
Ventajas: liquidez mejorada, mayor capital y volumen de operaciones (gracias a la componibilidad)
Desventajas: aumento de los costos de infraestructura, mala experiencia del usuario, congestión de la red
Sin embargo, DRiP utiliza principalmente Solana como infraestructura, distribuyendo millones de NFT de artistas a miles de billeteras cada semana, sin mucha necesidad de una alta componibilidad. El crecimiento del TVL y las entradas de capital de Solana han tenido poco impacto en DRiP y, en cambio, están plagados principalmente de altos costos de infraestructura.
Vibhu señaló que "la componibilidad genera rendimientos decrecientes". También mencionó que los desarrolladores de aplicaciones de Solana han discutido en privado su necesidad de acumulaciones porque estas acumulaciones pueden aumentar el rendimiento de las transacciones y reducir la competencia por el espacio de bloques. Además, existe un mayor control sobre el valor económico generado por el negocio.
Enlace de publicación
Solana ha experimentado múltiples eventos de congestión en los últimos meses, desde lanzamientos aéreos de JUP hasta minería ORE y comercio máximo de monedas meme. Si bien algunos creen que Firedancer podría resolver estos problemas, la realidad es que la línea de tiempo no está clara y actualmente no puede escalar más allá de 10x. A pesar de esto, Solana sigue siendo la única de todas las principales cadenas probadas en batalla que sigue siendo monolítica.
¿Solana debería seguir siendo una cadena monolítica o volverse modular?
¿Solana evolucionará hacia soluciones fragmentadas de Capa 2 y Capa 3 como Ethereum?
¿Cuál es el estado actual de la cadena de aplicaciones y Rollup de Solana?
Para responder a estas preguntas y elaborar un resumen, este artículo explorará las posibilidades y discutirá los pros y los contras de cada proyecto. Este artículo no entrará en detalles técnicos, pero analizará varios métodos de expansión y proporcionará una descripción general desde una perspectiva de aplicación práctica y orientada al mercado. Toda la información, sin tonterías, solo toneladas de información exclusiva.
En resumen, discutiremos los siguientes temas:
· Solana y problemas de congestión de la red
· Hacer que Solana sea modular
· Cadena de aplicaciones Solana - con ejemplos
· Solana Layer 2 y Rollup - con ejemplos
· Infraestructura que soporta Rollup y Cadena de Aplicaciones
Problemas con Solana y la necesidad de modularidad
Primero, analicemos los problemas actuales: debido a los lanzamientos aéreos y al aumento en el volumen de transacciones de memecoin, la red Solana ha estado muy congestionada recientemente (la mayor parte de la cual ya se ha resuelto), lo que resulta en tiempos de ping elevados, altas tasas de fallas en las transacciones y una mayor red. honorarios. A pesar de esto, Solana ha mantenido una capacidad de procesamiento de transacciones de entre 1.000 y 2.000 transacciones por segundo, superando todas las cadenas EVM combinadas. Se puede decir que este es un buen problema al que se enfrenta la cadena de bloques y también pone a prueba la teoría de la cadena monolítica de Solana.
La Fundación Solana publicó recientemente un blog instando a los proyectos a tomar acciones inmediatas para mejorar el rendimiento de la red, que incluyen:
· Implementar tarifas de prioridad: evitar transacciones retrasadas o perdidas es fundamental.
· Utilización óptima de las Unidades Informáticas del Programa (CU): utilice sólo los recursos necesarios.
· Implementar calidad de servicio (QoS) ponderada por participación: permitir que las aplicaciones prioricen las transacciones de los usuarios.
Sin embargo, estas medidas solo pueden mejorar la tasa de finalización de transacciones hasta cierto punto y no pueden garantizar una experiencia de transacción fluida. Una solución a este problema es el muy esperado Nuevo Programador de Transacciones, cuya introducción está prevista en la versión 1.18 a finales de abril. El nuevo programador existirá 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 programador anterior si surgen problemas. El nuevo planificador está diseñado para llenar bloques de manera más eficiente y asequible, mejorando las ineficiencias del antiguo planificador.
Lea este artículo para obtener más información sobre el nuevo programador.
Anza, una entidad bifurcada de Solana Labs, ha estado trabajando para resolver problemas de congestión de red que se han identificado como relacionados con el comportamiento de la implementación de QUIC y el manejo de grandes volúmenes de solicitudes por parte del cliente validador de Agave (Solana Labs).
Enlace de publicación
Aunque los defensores modulares defienden firmemente la "hoja de ruta modular" de Solana, Solana Labs/Anza, los principales mantenedores del protocolo Solana, todavía están centrados en optimizar los problemas de rendimiento y latencia de la capa base. Las posibles mejoras incluyen:
· Mercado de tarifas mejorado y tarifa base aumentada (actualmente fijada en 5000 Lamports o 0,000005 SOL).
· Implementar aumentos exponenciales en las tarifas de bloqueo de escritura de cuentas, es decir, aumentar gradualmente las tarifas para frenar el spam.
· Optimizar las solicitudes de presupuesto de la CU a través de mecanismos de sanción.
· Mejorar la arquitectura general de la red.
Incluso si estas mejoras de escalamiento vertical, cadena única, son efectivas, no podemos descartar la posibilidad de que Solana adopte el escalamiento horizontal, Rollup. La realidad es que Solana puede combinar estas dos características: puede servir como una excelente capa base de Rollup, con un tiempo de bloque de latencia ultrabaja (~400 milisegundos), lo que mejora significativamente el rendimiento de Rollup, como al permitir una rápida confirmación suave del secuenciador. Además de eso, Solana tiene un historial de implementar cambios rápidamente, lo que puede hacerlo más eficiente que Ethereum como capa base para Rollup.
Actualización: Anza ha implementado parches para ayudar a aliviar los problemas actuales de congestión de la red y se mejorarán aún más en la versión 1.18.
Hacer que Solana sea modular
El plan de desarrollo modular de Solana ha comenzado. Como muestra la publicación de Anza DevRel, Anza conecta y mantiene estrechamente el validador de Solana y SVM (el entorno de ejecución que maneja transacciones y contratos/programas inteligentes). Sin embargo, el cliente validador y el tiempo de ejecución SVM se separarán en los próximos meses. Esta separación ayudará a crear una "cadena de aplicaciones Solana".
Para Rollup, la optimización de la disponibilidad de datos (DA) o la capa de blobs de Solana se puede realizar en una etapa posterior.
Información de: Anza DevRel
El ingeniero de Anza, Joe C, también reveló planes para modularizar el SVM, donde la canalización de procesamiento de transacciones se quitará del validador y se colocará en el SVM. Esto permitirá a los desarrolladores ejecutar implementaciones de SVM independientemente de cualquier validador.
Una SVM independiente sería una colección de módulos completamente independientes. Cualquier implementación de SVM puede impulsar estos módulos a través de interfaces bien definidas, lo que reduce aún más las barreras para los proyectos compatibles con SVM y reduce significativamente los gastos generales necesarios para crear soluciones personalizadas. Los equipos pueden implementar solo los módulos que les interesan mientras aprovechan las implementaciones establecidas, como las de Agave o Firedancer.
En resumen, Solana será más plug-and-play, lo que hará que las cadenas de aplicaciones y los paquetes acumulativos de Solana sean más fáciles de implementar.
En términos generales, esto puede ir en dos direcciones: Capa2 (o Rollup) y cadena de aplicaciones. A continuación los presentaremos uno por uno.
Cadena de aplicaciones de Solana
También conocidas como horquillas SVM, son esencialmente horquillas de la cadena Solana diseñadas para aplicaciones específicas. Pyth fue la primera cadena de aplicaciones de Solana, pero el concepto realmente llamó la atención cuando el fundador de Maker, Rune, propuso desarrollar una cadena de aplicaciones de Maker para la gobernanza basada en el código base de Solana (SVM). Rune eligió SVM debido a su sólida comunidad de desarrolladores y ventajas técnicas sobre otras VM, con el objetivo de bifurcar la cadena de mayor rendimiento para satisfacer mejor las necesidades de los consumidores. Aunque aún no se ha implementado, esta medida ha provocado un debate generalizado sobre la cadena de aplicaciones de Solana.
En términos generales, se puede dividir en dos categorías:
· No se requiere permiso: cualquiera puede unirse a la red, similar a la red principal actual de Solana.
· Permiso: "Entornos autorizados (SPE) de Solana" empaquetados por la Fundación Solana para instituciones, que permiten a las entidades crear y mantener sus propias instancias de cadena, respaldadas por SVM.
Cadena de aplicaciones Pyth - OG Solana:
Python alguna vez representó entre el 10 y el 20% de todas las transacciones en la red principal de Solana. Sin embargo, no requería ninguna capacidad de composición, por lo que simplemente bifurcaron el código base de Solana. Esto les permite aprovechar los rápidos tiempos de bloque de 400 milisegundos de Solana para actualizaciones de precios de alta frecuencia. Python es la primera red en adoptar SVM como cadena de aplicaciones.
Pythnet Application Chain es una bifurcación de prueba de autoridad de la red principal de Solana y sirve como capa base computacional para procesar y agregar datos proporcionados por Pyth Data Publishing Network.
¿Por qué está migrando Python?
· No requiere una alta componibilidad, especialmente para aplicaciones que no son de Solana y, por lo tanto, es inmune a la congestión de la red principal.
· Requiere un entorno autorizado para publicar datos.
· Reducir los costes de infraestructura internalizando tarifas que anteriormente se habrían filtrado a la capa base, que es Solana.
Cube Exchange es otro ejemplo, un CEX híbrido implementado como una cadena SVM soberana con una cartera de pedidos completamente fuera de línea y liquidación en su cadena SVM.
Ejemplo de cadena de aplicaciones de Solana
· Perp DEX: los Perp DEX como Hyperliquid pueden ejecutarse como redes independientes de Capa 1. Además, para casos de uso comercial, es posible personalizar el número de transacciones por bloque o implementar lógica condicional, como integrar la ejecución de órdenes stop directamente en la Capa 1, garantizar que se apliquen como transiciones de estado o introducir aplicaciones- Lógica de átomos específicos.
· AI y DePIN: Pueden tener una lista controlada de proveedores de servicios, como Pyth. Por ejemplo, Akash opera como un mercado informático a través de la cadena de aplicaciones Cosmos.
· Cadena de aplicaciones de gobernanza: como lo verifica el interés de MakerDAO en las cadenas de aplicaciones SVM, las cadenas de aplicaciones de gobernanza soberana pueden ser muy atractivas. La criptogobernanza todavía está evolucionando y tener bifurcaciones de cadena dedicadas puede ser un mecanismo de coordinación útil.
· Cadenas de aplicaciones empresariales futuras: Las aplicaciones potenciales incluyen fondos como BlackRock o sistemas de pago como Visa o CBDC.
· Cadena de aplicaciones de juegos: un proyecto de juegos de casino que se ejecuta en Solana está considerando su cadena de aplicaciones.
· Modificaciones a una bifurcación de Solana: similar a la EVM (paralelización) optimizada proporcionada por Monad o Sei, alguien podría crear una versión más optimizada de Solana. Es probable que esta tendencia prevalezca en los próximos años a medida que la red principal de Solana comience a explorar nuevas arquitecturas de diseño.
Imagine la pila de cadenas de aplicaciones de Solana
Si bien configurar cadenas de aplicaciones puede ser relativamente sencillo, garantizar la conectividad entre todas las cadenas de aplicaciones es fundamental para la interoperabilidad. Inspirándose en la subred Avalanche, conectándose a través de cadenas de aplicaciones nativas Avalanche Warp Messaging y Cosmos, conectándose a través de IBC, Solana también puede crear un marco de mensajería local para conectar estas cadenas de aplicaciones.
Enlace de publicación
Se puede crear una plataforma de middleware como Cosmos-SDK para proporcionar un servicio integral para crear cadenas de aplicaciones con soporte integrado para oráculos como Pyth o Switchboard, llamadas a procedimientos remotos, RPC como Helius y conexiones de mensajería como Wormhole. y otras funciones.
AggLayer de Polygon proporciona una solución innovadora que permite a los desarrolladores vincular diferentes Capas 1 o 2 en AggLayer para lograr la agregación de pruebas ZK entre cadenas.
¿Cuál es el impacto positivo de Application Chain en el ecosistema de Solana?
Las cadenas de aplicaciones no pagan tarifas en SOL ni utilizan SOL como token de tarifa de transacción, por lo que no aportan valor directamente a SOL a menos que SOL vuelva a apostar por motivos de seguridad económica, pero sus beneficios para el ecosistema SVM son obvios. Al igual que el efecto de red de EVM, más bifurcaciones y cadenas de aplicaciones de SVM fortalecerán el efecto de red de SVM. Esta lógica también se aplica incluso si Eclipse, como extensión de Capa 2 de SVM en Ethereum, compite con la red principal de Solana.
Capa 2 de Solana
Solana Layer 2, o Rollup, es una cadena lógicamente independiente que publica datos en la capa de Disponibilidad de datos (DA) de su cadena principal y reutiliza el mecanismo de consenso de la cadena principal. También pueden usar otras capas DA como Celestia, pero esto ya no es un verdadero resumen. El término "RollApp" se utiliza a menudo para paquetes acumulativos específicos de aplicaciones (que la mayoría de las aplicaciones de Solana están explorando).
¿Será el Rollup de Solana como Ethereum?
Obviamente no. Para Solana, Rollup se abstraerá principalmente para los usuarios finales. Desde un punto de vista ideológico, el Rollup de Ethereum es de arriba hacia abajo, es decir, la Fundación Ethereum y los líderes decidieron que la mejor manera de escalar era a través del Rollup, y luego comenzaron a admitir varias Capas 2 después del incidente de CryptoKitties. En Solana, la demanda viene de abajo hacia arriba, de los desarrolladores de aplicaciones con una adopción significativa por parte de los usuarios. Como resultado, la mayoría de las jugadas acumuladas actuales son jugadas de marketing que están más impulsadas por la narrativa que por las necesidades del usuario. Esta es una diferencia significativa que podría conducir a un futuro diferente para Rollup que para Ethereum.
¿La compresión es equivalente a Rollup?
La Capa 2 extiende la cadena de bloques de la capa base (Capa 1) ejecutando transacciones en la Capa 2, agrupando datos de transacciones por lotes y comprimiéndolos. Luego, los datos comprimidos se envían a la Capa 1 y se utilizan como prueba de fraude (acumulación optimista) o prueba de validez (acumulación zk). Este proceso de certificación se llama "liquidación". De manera similar, la compresión descarga las transacciones de la red principal, lo que reduce la contienda por el estado de la capa base. Vale la pena señalar que Grass Layer 2 utilizará compresión de estado para su acumulación.
Patrón acumulativo en Solana:
Actualmente hay dos proyectos similares a Rollapps en ejecución:
Obtener código
Es una aplicación de pagos con un SDK de micropagos que permite a cualquier persona realizar y aceptar pagos al instante y utilizar una estructura similar a un resumen para su aplicación. Crea intenciones para todas las transacciones y utiliza un secuenciador tipo resumen para establecerse en Solana cada N intervalos.
Esto se puede lograr utilizando una estructura similar a un resumen:
· Flexibilidad: Las intenciones pueden representar una variedad de actividades futuras, no solo transacciones de pago. Además, Solana como cadena se puede sustituir si es necesario.
· Inmediatez y privacidad: debido a la suave finalidad del secuenciador, los pagos son instantáneos incluso durante la congestión de Solana. Si bien las transacciones son visibles en la cadena, los montos y las intenciones exactos siguen siendo oscuros, lo que garantiza la privacidad del usuario.
Paquete acumulativo de corta duración para MagicBlocks
MagicBlocks es una infraestructura de juegos web3 desarrollada con Ephermal Rollup específicamente para juegos. Utiliza la estructura de cuentas de SVM para dividir el estado del juego en grupos. Luego, el estado se transfiere temporalmente a una capa secundaria o "acumulación efímera", una capa dedicada configurable. El resumen efímero se ejecuta como un tiempo de ejecución de SVM dedicado o un resumen para procesar transacciones con un mayor rendimiento.
Esto se puede lograr utilizando una estructura similar a un resumen:
· Personalización de tiempos de ejecución dedicados, incluidas transacciones sin gas, tiempos de bloqueo más rápidos y mecanismos de sincronización integrados, por ejemplo, sistemas integrados de programación de transacciones como Clockwork que se ejecutan sin costo.
· Los desarrolladores pueden implementar programas en una capa base, como Solana, en lugar de en una cadena o paquete acumulativo separado. Los rollups efímeros no fragmentan el ecosistema existente, lo que permite acelerar las operaciones objetivo sin crear un entorno aislado. Esto significa que se puede aprovechar toda la infraestructura existente de Solana.
Este enfoque ayuda a crear un sistema altamente escalable capaz de lanzar paquetes acumulativos bajo demanda y escalar automáticamente horizontalmente para dar cabida a usuarios que ejecutan millones de transacciones sin las típicas compensaciones de la Capa 2 tradicional. Si bien MagicBlock se centra en los juegos, este enfoque también se puede aplicar a otras áreas, como los pagos.
Próximo resumen de Solana:
· Grass: Grass es un proyecto DePIN que se enfoca en resolver las necesidades de datos de la inteligencia artificial a través de tecnología de verificación y captura. El proyecto captura datos de entrenamiento de IA a través de nodos Grass en la red y los validadores almacenan los datos en la cadena de bloques, mientras registra con precisión la fuente de los datos y el nodo que realizó la captura, y lo recompensa en consecuencia.
Dado que Grass necesita manejar hasta 1 millón de solicitudes de red por segundo, esto no es realista para la red principal de Solana. Por lo tanto, el proyecto planea utilizar tecnología de prueba de conocimiento cero para verificar el conjunto de datos y establecerlo en lotes en la Capa 1 de Solana.
El equipo de Grass también está considerando introducir tecnología de compresión de estado de otros clústeres y realizar el anclaje de datos en la versión beta de la red principal de Solana. Esta innovación convertirá a Grass en una plataforma fundamental, que admitirá una amplia gama de aplicaciones que solo se pueden construir sobre ella.
*Tenga en cuenta que los proyectos que construyen plataformas e infraestructura generalmente tienen valoraciones de mercado más altas y Grass está a punto de lanzar su token.
· Zeta: Uno de los primeros intercambios de contratos perpetuos en Solana, que tiene una cartera de pedidos perpetuos enteramente en la cadena, actualmente planea utilizar la tecnología Rollup de Solana para migrar su proceso de emparejamiento comercial fuera de la cadena.
Los intercambios de contratos perpetuos que utilizan la tecnología Rollup tienen ventajas obvias porque mejora enormemente la experiencia comercial del usuario. Pregúntele a quienes han operado en plataformas como Hyperliquid o Aevo con intercambios de contratos perpetuos en Solana, que requieren que los usuarios firmen cada transacción, una ventana emergente de billetera y una espera de entre 10 y 20 segundos. Además, las transacciones de contratos perpetuos no requieren ejecución simultánea y pueden integrarse altamente con otras partes del ecosistema DeFi, especialmente en términos de coincidencia de transacciones.
Curiosamente, Armani, cofundador de Backpack, también tuiteó que ahora se están centrando en soluciones de Capa 2.
Sonic está desarrollando una cadena SVM modular llamada Hypergrid que permitirá a los desarrolladores de juegos implementar sus propias cadenas en la plataforma Solana. Al mismo tiempo, también existen proyectos Ethereum Rollup basados en tecnología SVM, como Eclipse y NitroVM, que utilizan SVM como motor de ejecución. En el ecosistema de Solana, Neon sirve como una solución de Capa 2 compatible con EVM. Además, algunos proyectos innovadores como Molecule, un SVM Layer 2 para Bitcoin, aún se encuentran en una etapa conceptual inicial.
Sovereign SDK proporciona un marco similar a node.js específicamente para crear paquetes acumulativos. Los usuarios pueden enviar su código Rust y la plataforma puede convertirlo en un Optimistic Rollup o ZK Rollup que admite la implementación en cualquier blockchain. Este código Rust puede ser una lógica de aplicación personalizada o cualquier implementación de máquina virtual.
Algunos argumentos sobre Rollup
Resumen = consistente con SOL
“ETH-Aligned” o “ETH Bag Biases” se ha convertido en un meme popular en Internet.
¿Por qué la Capa 2 y la Resting/EigenLayer se están convirtiendo en los temas más candentes?
Esto se debe a que aumentan el "dinero" de ETH, que se utiliza como activo principal en todas partes.
El mismo principio se aplica a Solana. La comunidad de Solana apoyará cualquier solución que aumente sus tenencias de SOL: así de simple. A medida que el ecosistema de Solana se expanda, la “moneda” de SOL, que alguna vez se pasó por alto, se volverá importante. Recuerde, la mayoría de los Rollups son "estrategias de marketing" de todos modos y, dado que el mercado todavía valora la infraestructura por encima de las aplicaciones, ofrecen una mejor acumulación de valor simbólico.
Rollup se sentirá como una extensión de Solana
Además de los beneficios de seguridad de heredar la seguridad de la capa base, el fácil acceso a los usuarios y activos de Solana será una ventaja significativa. Como señaló Jon Charbonneau, los rollups de Ethereum como Base, Optimism y Arbitrum se parecen más a extensiones de Ethereum. Los usuarios mantienen la misma billetera y dirección, el token de gas nativo es una única versión estándar de ETH, ETH domina DeFi, todos los pares comerciales son ETH, las aplicaciones sociales valoran los NFT en ETH y pagan a los creadores, por ejemplo, friend.tech, y los depósitos de Capa 2 son instantáneos. etc.
Lo mismo ocurrirá con Solana. Aprendiendo de Ethereum, la mayoría de Solana Rollapps no harán que los usuarios sientan que están usando una cadena separada, por ejemplo, Getcode.
Solana verá más "RollApps" que "Rollup"
Solana no tiene problemas de escala como Ethereum, donde la red principal se vuelve difícil de usar debido a las altas tarifas del gas, está altamente optimizada. Sin embargo, algunas aplicaciones que requieren espacio de bloque dedicado crearán sus paquetes acumulativos. Si bien un Rollup universal en Solana no tiene sentido para mí, financieramente sí tiene sentido para el proyecto. Por ejemplo, ¡los usuarios de Base generaron $2 millones en ingresos para Coinbase en solo un día! Los incentivos para los constructores se inclinan fuertemente hacia la Capa 2. Sin embargo, como se observó, cada EVM Rollup parece ser un Rollup normal, y muchos proyectos como Linea, Scroll o zkSync se han convertido en cadenas fantasma en las que solo los agricultores realizan algunas transacciones para lanzamientos aéreos de tokens.
Además, creo que una Capa 2 universal en Solana puede conducir a los mismos viejos problemas que Ethereum, es decir, acumulación centralizada, congestión y fragmentación de liquidez.
¿Por qué algunas aplicaciones quieren migrar a Rollapps/AppChain?
Cada aplicación se lanzará inicialmente en la red principal de Solana, ya que alojar más aplicaciones en una infraestructura compartida reduce significativamente la complejidad para los desarrolladores y usuarios. Sin embargo, a medida que estas aplicaciones crezcan, 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 solo para una aplicación. La captura de MEV podría ser otra opción rentable para los DEX.
· Espacio de bloque dedicado.
· Personalización dentro de los casos de uso. Por ejemplo, en términos de privacidad, Getcode utiliza un secuenciador para proporcionar a sus usuarios pagos privados, experimentos de tarifas de mercado, grupos de memoria cifrados que minimizan MEV y libros de pedidos personalizados.
Sin embargo, no todas las aplicaciones querrán iniciar su propio Rollup, especialmente aquellas que no alcanzan una cierta velocidad de escape, por ejemplo, suficiente TVL, usuarios o volumen de transacciones. Lanzar su propia cadena hoy implica compensaciones dolorosas e innecesarias, complejidad, costos, peor experiencia de usuario, fragmentación de la liquidez, etc. La mayoría de las aplicaciones, especialmente aquellas en las primeras etapas, no pueden justificar las ganancias incrementales. Solana sigue siendo el corazón y el alma del desarrollo de SVM, por lo que es probable que se implementen muchas aplicaciones nuevas.
Para creadores de aplicaciones
La red principal, la cadena de aplicaciones o el paquete acumulativo de Solana dependen completamente de diferentes situaciones. Si no existe una gran necesidad de componibilidad con otras aplicaciones, es completamente razonable colocar algunos componentes diferentes fuera de la cadena, ya sea la cadena de aplicaciones o el Rollup. Los usuarios ni siquiera necesitan saber que están utilizando Rollup o AppChain. Grass, Zeta y Getcode abstraen cualquier infraestructura de tipo Rollup que utilicen para sus usuarios.
Para casos de uso que requieren autorización y personalización, Token Extension también puede satisfacer la mayoría de las necesidades, como KYC o lógica de transferencia, manteniendo la componibilidad.
Infraestructura que impulsa la cadena acumulativa y de aplicaciones
Si se amplía la teoría de Rollapp/Cadena de Aplicaciones, los proveedores de infraestructura existentes podrán beneficiarse significativamente a medida que ingresen a nuevos mercados:
· Los proveedores existentes de Rollup como servicio (RaaS), como Caldera, pueden ingresar fácilmente al mercado SVM a medida que surge la demanda. SVM como Eclipse y NitroVM también están atentos a esta oportunidad. Además, Sovereign Labs proporciona un adaptador Sovereign SDK Solana que admite Rollup en Solana (aún no está listo para producción). Helius es otra empresa que está bien preparada para construir infraestructura para Solana Layer 2, como Mert ha insinuado varias veces.
· Secuenciadores compartidos como el Protocolo de Roma y la necesidad de clientes ligeros como Tinydancer. Los secuenciadores compartidos podrían ser interesantes para Rollup, ya que permiten actividades como el arbitraje atómico, MEV y puentes sin interrupciones, lo que reduce la fragmentación de la liquidez.
· Carteras como Phantom, Backpack y Solflare. Infraestructura de billetera de contratos inteligentes y de firmas múltiples, como Squads. Squads se ha posicionado como "la capa de infraestructura de billetera de contrato inteligente definitiva para Solana y SVM".
· Volver a apostar SOL: La teoría de la modularidad también promueve el volver a apostar, ya que estas cadenas acumuladas/de aplicaciones pueden requerir que SOL comparta la seguridad y sea más consistente con Solana. Esto generará mayores ingresos para los primeros usuarios como Cambrian, Picaso y Solayer, Jito a través de Stakenet y LST como Sanctum, así como para los validadores.
Por último, ¿podrá Solana hacer frente a la demanda global?
Por supuesto que no. De manera realista, incluso teniendo en cuenta la Ley de Moore, incluso si el hardware continúa mejorando el rendimiento y Solana está optimizado para este avance del hardware, esto no es realista. Creo que todas las transacciones menos críticas, como el envío de NFT por DRiP, 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 crucial, como el DEX al contado.
Esto no significa que Solana esté perdiendo la batalla de la monolítica y la componibilidad; se manejará mejor que otras cadenas confiando en la componibilidad y la baja latencia. Además, Sui, Aptos, Sei, Monad, etc. no son mejores porque aún no sabemos si resisten una alta actividad real de los usuarios.
A diferencia de Ethereum, la red principal de Solana no pretende ser una "cadena B2B", siempre ha sido y será una cadena de consumo; Construir sistemas distribuidos a escala es un gran desafío y Solana tiene el mayor potencial para convertirse en el libro de contabilidad compartido de las transacciones más valiosas del mundo.
Solana necesita un alma gemela: ¿podrían AppChain y Rollup ser la combinación perfecta?
Enlace original
