Autor: Ian Xu@Foresight Ventures
TL;DR
Este artículo presenta Rollup-as-a-Service, que satisface las crecientes y diversas necesidades de Dapps. RaaS permite que las Dapps mantengan un alto rendimiento, reduzcan costos y brinden mejores experiencias de usuario sin comprometer su interacción con el ecosistema más amplio.
Si bien RaaS tiene potencial, la principal ventaja de RaaS parece ser sus opciones de personalización y, en general, la demanda de RaaS es actualmente limitada y su valor necesita una mayor exploración.
Si bien los paquetes acumulativos optimistas actualmente lideran debido a una mejor compatibilidad y umbrales más bajos, los paquetes acumulativos de conocimiento cero pueden llegar a dominar debido a su rendimiento y personalización superiores.
Este artículo compara L3 y L2 para RaaS y RaaS con las cadenas de aplicaciones, lo que indica que RaaS puede proporcionar una mejor interoperabilidad y seguridad si se construye un ecosistema sólido.
Este artículo analiza varios proyectos RaaS para determinar los enfoques más prometedores. Cubre proyectos basados en ZK (como StarkWare y Opside), proyectos basados en Optimistic (como Caldera) y soluciones Modular Blockchain (como Celestia).
1. Introducción a RaaS
1.1 Rollup: la solución de escalabilidad más prometedora
La intención inicial de la Capa 2 es aliviar el problema de congestión de la mainnet y brindar servicios para Dapps con menores costos y mayor TPS bajo la premisa de garantizar la seguridad. Rollup ejecuta la ejecución de transacciones de alto costo en L2 y empaqueta las transacciones en L1 para su verificación, al tiempo que garantiza que se pueda verificar el contenido completo de la transacción. Bajo la premisa de heredar la seguridad de Ethereum, tiene un rendimiento integral más sólido. Por lo tanto, el rollup se ha abierto paso entre varias soluciones de Capa 2 y es sin duda la solución de escalamiento fuera de la cadena más prometedora en la actualidad.
1.2 Rollup-as-a-service: una forma de cadena específica de la aplicación
Con el crecimiento gradual de algunas Dapps y la expansión de varias aplicaciones nuevas, el rollup como escalado de propósito general no puede satisfacer perfectamente la búsqueda de experiencia de usuario y estructura de costos de estos proyectos. El alto tráfico y los requisitos de alto rendimiento (como los juegos AAA que se centran en la interacción del jugador) hacen que estas aplicaciones necesiten soluciones de escalabilidad más personalizadas.
La cadena específica de aplicaciones es una de las mejores soluciones para estas Dapps.
El concepto de cadena de aplicaciones no es extraño. Diferentes proyectos pueden personalizar el diseño de blockchain de acuerdo con sus propios escenarios y necesidades de aplicación, lo que permite a las Dapps disfrutar exclusivamente de los recursos de una cadena. Si bien garantizan no separarse de otros ecosistemas, pueden lograr menores costos operativos y mayor rendimiento, brindando una mejor experiencia de usuario.
Por ejemplo, Cosmos, basado en el consenso de Tendermint, proporciona a Dapps un entorno de bajo costo para construir una cadena pública soberana L1. Al mismo tiempo, según el protocolo de comunicación IBC, diferentes cadenas de aplicaciones pueden lograr más fácilmente activos/información entre cadenas. Puede consultar el ciclo de vida del paquete IBC proporcionado por el funcionario de Cosmos👇
Hablar de escalabilidad sin considerar el ecosistema no tiene sentido.
La viabilidad de la solución de la cadena de aplicaciones se basa definitivamente en una sólida interoperabilidad y soporte del ecosistema. Por ejemplo, Cosmos mejora gradualmente su propio ecosistema a través de la cadena pública soberana L1 y las ventajas entre cadenas aportadas por IBC en el ecosistema.
Con base en el entendimiento anterior, otra idea de la cadena específica de la aplicación es lograr la búsqueda de funciones personalizadas, alto rendimiento y bajo costo por parte de Dapp a través de un roll-up personalizado. Algunos RaaS basados en la red de segunda capa también pueden hacer que la interacción del proyecto sea más conveniente y tener un impacto positivo en el diseño ecológico.
2. El valor de RaaS
La tendencia de múltiples cadenas y acumulaciones en el mundo de las criptomonedas parece inevitable. La aparición de proyectos RaaS como los brotes de bambú de primavera ha sentado las bases para el desarrollo de nuevas formas de Dapp. Pero ante tal consenso, todavía quiero hacer una pregunta realista en la dirección opuesta:
De hecho, es atractivo permitir que cualquiera lance rápidamente un paquete acumulativo, pero además de estar en la dirección correcta y ser interesante, ¿realmente crea suficiente valor para quienes lo necesitan? Esta pregunta se puede dividir en dos puntos:
Si hay suficientes proyectos en el mercado que tengan suficiente motivación para utilizar RaaS;
Si RaaS ha creado un valor considerable para las partes del proyecto.
Esta pregunta analiza esencialmente la demanda y el valor que aporta RaaS. Hay suficientes proyectos que tienen demanda o RaaS puede proporcionar mejoras atractivas.
En términos de demanda, a medida que algunas Dapps continúan creciendo, las partes del proyecto deben buscar urgentemente:
Costo más bajo
Mayor rendimiento
Funciones especiales
Costo
En referencia a los datos proporcionados por L2fees, el paquete acumulativo de L2 ha logrado lo último en optimización de costos, lo cual es una gran mejora en comparación con la red principal de Ethereum. Al observar nuevamente los datos de prueba de RaaS de Caldera Chains, no hay ningún cambio cualitativo en el costo, más bien una optimización 99-100. Al mismo tiempo, la implementación de EIP4844 y danksharding reducirá aún más el costo de la acumulación L2, y la diferencia que aporta RaaS en costo y eficiencia también se reducirá aún más.
Una solución que puede reducir significativamente la tarifa de transacción es atractiva, pero la mayoría de RaaS no pueden hacerlo. Teniendo en cuenta la migración, la ecología general, la interoperabilidad, la seguridad y otros costos, ¿las partes del proyecto realmente tienen suficiente motivación para utilizar RaaS? Para la mayoría de las Dapps convencionales o para los usuarios que no son tan sensibles al rendimiento y el costo, quizás el escalado de propósito general sea suficiente.
Actuación
El paquete acumulativo L2 ya tiene la capacidad de proporcionar un TPS ultraalto. Con referencia a los datos proporcionados por Caldera, RaaS basado en Op casi no tiene ventaja en el tiempo de bloqueo. Aunque ZK RaaS puede proporcionar almacenamiento y compresión de datos más personalizados, no hay mucha demanda de dichos servicios. De hecho, RaaS basado en la red de segunda capa puede lograr una velocidad más rápida y un menor costo al liquidar transacciones en L2, mejorando así la experiencia del usuario.
Como se mencionó anteriormente, frente al ecosistema imperfecto y otros costos de migración/desarrollo, ¿las partes del proyecto todavía tienen suficiente motivación para usar RaaS?
Funciones personalizadas
En términos de creación de valor, algunos RaaS pueden proporcionar características que actualmente son difíciles de implementar o diseños que son ineficientes en el escalamiento de propósito general. Por ejemplo:
El primer elemento del diseño del circuito ZK del L2 actual es la compatibilidad. Para servir a todas las Dapps, el diseño del circuito sacrifica la eficiencia hasta cierto punto y no optimiza para Dapps específicas. El valor de RaaS se puede demostrar claramente: personalizar el diseño del circuito ZK para Dapps específicas o proporcionar estructuras de almacenamiento y servicios de compresión de datos más eficientes para lograr un mayor rendimiento;
Implementación de funciones de privacidad. Aunque el paquete acumulativo de ZK es respetuoso con la privacidad, debido a consideraciones de descentralización y seguridad, los datos de las transacciones de los usuarios aún deben publicarse en L1 como un registro histórico después de la compresión, lo que permite que todos los usuarios los verifiquen. Por lo tanto, el actual paquete acumulativo de escalado de propósito general no puede lograr la privacidad. RaaS puede personalizar la implementación de funciones de privacidad sobre la base de un resumen o incluso un resumen de resumen, creando valor para proyectos con fuertes necesidades de privacidad.
Por lo tanto, el valor actual de RaaS es la personalización > puro costo y eficiencia. (Sin excluir las mejoras de costo y eficiencia aportadas por la personalización)
Para responder a la pregunta inicial: ¿RaaS realmente crea suficiente valor para las personas que lo necesitan?
Creo que la demanda actual de RaaS es limitada y el escalado de propósito general puede satisfacer más del 90% de las necesidades. Aunque los paquetes acumulativos personalizados han comenzado a desempeñar un papel irremplazable en algunas áreas específicas, después de todo no son comunes. El valor creado por RaaS es limitado y debe explorarse más a fondo teniendo en cuenta el ecosistema, la interoperabilidad y otros factores integrales.
3. Explorando la forma definitiva de RaaS
Desde la aparición del paquete acumulativo L2, la exploración de RaaS nunca se ha detenido y hasta ahora han aparecido en el mercado varias soluciones de implementación de paquete acumulativo como servicio. En referencia al diseño del ecosistema en Messari, puede ver aproximadamente las rutas de implementación de diferentes RaaS. Entonces las preguntas clave son:
¿Qué soluciones tienen sentido?
¿Qué tipo de RaaS acabará ganando el mercado?
3.1 OP o ZK？
La discusión sobre el conocimiento optimista o nulo nunca ha cesado. Aunque, en teoría, ZKrollup tiene un rendimiento más sólido, un tiempo de finalidad mucho más rápido que el resumen optimista y una mayor seguridad, el resumen optimista tiene una mejor compatibilidad y un umbral más bajo.
En los proyectos RaaS existentes, la mayoría de los proyectos se basan principalmente en acumulaciones optimistas. Creo que las principales razones son:
El ecosistema siempre es lo primero. RaaS basado en optimista tiene una mejor compatibilidad, lo que reduce en gran medida el umbral para que las partes del proyecto migren/desarrollen, lo que permite que más partes del proyecto se implementen rápidamente, construyan rápidamente un ecosistema más próspero y ocupen la ventaja de ser los primeros en moverse.
Umbral inferior, que no depende del soporte de potencia informática. RaaS basado en Optimistic también verifica la validez de las transacciones a prueba de fraude, por lo que los requisitos de rendimiento y reservas de la máquina son menores en términos de potencia informática. Este también es un factor limitante para muchos RaaS que no pueden comenzar con ZK**.**
Más fácil de escalar. El umbral de desarrollo de RaaS basado en optimista es más bajo, a diferencia de ZK RaaS, que busca rendimiento y una mayor personalización subyacente, lo que requiere que los proveedores participen profundamente en el desarrollo. Al mismo tiempo, limitado por la potencia informática para generar ZKP, ZK RaaS es difícil de implementar a gran escala como RaaS optimista.
Aunque el resumen optimista tiene ventajas obvias en el diseño ecológico, RaaS basado en ZK también tiene ventajas obvias.
Verdadera personalización, mejor rendimiento y menor costo. En el diseño de personalización acumulativa, RaaS basado en ZK puede aportar mayor valor al proyecto en términos de funciones y rendimiento, lo que es difícil de lograr con el escalamiento de propósito general. Puede verse como un cambio de 0 a 1. RaaS basado en optimista se trata más de realizar cambios de 90 a 99 en términos de costo y eficiencia.
Mayor seguridad. El RaaS de ZK puede no ser confiable, mientras que los servicios basados en operaciones requieren confianza en el retador para funcionar normalmente y evitar que el secuenciador haga el mal.
Mejor interoperabilidad y tiempo de finalidad. RaaS basado en OP necesita llevar a cabo una verificación a prueba de fraude de 7 días, mientras que la característica sin confianza de ZK le brinda un tiempo de finalidad más rápido, y el período de verificación de 7 días hace que OP-RaaS enfrente desafíos en la construcción de paquetes cruzados.
Resumen
A corto plazo, la ventaja ecológica de RaaS basada en el optimismo es inquebrantable, pero desde la perspectiva de la demanda a largo plazo y la creación de valor, creo que es probable que RaaS basada en ZK gane una mayor participación de mercado en el futuro.
3.2 ¿Capa 2 o Capa 3?
Dependiendo del caso de uso y los objetivos de implementación de los diferentes RaaS, se debe elegir el plan de implementación más adecuado. En mi opinión, la mayor diferencia radica en el coste y la experiencia de usuario (interoperabilidad).
Al posicionar la Capa 2 (L2) como la capa de liquidación y organizar RaaS como la Capa 3 (L3), se pueden lograr menores costos de transacción e interacciones cruzadas más rápidas, mejorando así la experiencia general del usuario. Aunque L2 RaaS basado en Ethereum ha heredado con éxito la seguridad de la red principal, su costo y velocidad entre cadenas son muy inferiores a los diseños de redes multicapa.
Por lo tanto, L3 > L2
Para obtener más información sobre la Capa 3, puede consultar un artículo que escribí anteriormente:
Foresight Ventures: explicación detallada de Layer3
3.3 Cadena de aplicaciones RaaS o L1: equilibrio entre ecosistema y costo
Cosmos y Polkadot fueron los primeros en proponer una solución de cadena específica para aplicaciones. Entonces, entre la cadena específica de aplicaciones y RaaS, ¿cuál es más adecuada para brindar servicios personalizados para dapps?
Interoperabilidad
Para las cadenas de aplicaciones L1, además del ecosistema Cosmos basado en el protocolo de comunicación IBC mencionado en la primera sección, las aplicaciones pueden establecer paracaídas en Polkadot y realizar intercambio de información entre cadenas basado en XCM. Sin embargo, debido a consideraciones de seguridad y costo, en aplicaciones reales, podemos ver que la mayoría de los proyectos solo se basan en el motor de consenso Tendermint o Substrate para desarrollar cadenas de aplicaciones L1 personalizadas y rara vez utilizan comunicación entre cadenas. Esto conduce a una relativa independencia entre estos ecosistemas entre cadenas; hasta cierto punto, no se ajusta a mi visión final de la cadena de aplicaciones, donde diferentes cadenas de aplicaciones deberían formar juntas un ecosistema próspero con una fuerte interoperabilidad.
Para estructuras como StarkNet que amplían aún más RaaS basado en redes de Capa 2, tienen una mayor ventaja en términos de interoperabilidad. Diferentes dapps que mantienen sus paquetes acumulativos pueden realizar cadenas cruzadas de bajo costo y, debido a que pueden instalarse en redes de Capa 2, la velocidad y la experiencia del usuario serán mejores. Sin embargo, todas estas premisas de interoperabilidad se basan en que RaaS sea capaz de construir un ecosistema suficientemente fuerte.
Seguridad
Dependiendo del diseño de RaaS, DA basado en RaaS de Ethereum hereda principalmente la seguridad equivalente a Ethereum L1, que es más alta que el nivel de seguridad y descentralización de las cadenas de aplicaciones L1. Para RaaS basado en la capa DA o cadena lateral, la seguridad está garantizada por estas redes de Capa 2.
Costo
Para las cadenas de aplicaciones L1, los costos de transacción convergen con el token nativo del propio proyecto dapp, lo que puede lograr costos operativos extremadamente bajos;
Para RaaS, L2 RaaS tiene un costo relativamente alto porque necesita interactuar directamente con la red principal de Ethereum, mientras que L3 RaaS basado en Polygon, StarkNet, etc., puede instalarse en L2, por lo tanto, tienen costos relativamente más bajos.
4. Análisis del proyecto RaaS: quién ganará el mercado de RaaS
Hay muchos proyectos RaaS actualmente en desarrollo o ya implementados, incluidos, entre otros, StarkNet L3, Opside, Caldera, Celestia, Dymension, Sovereign, Stackr, Eclipse, Altlayer, Saga...
A continuación se presentan algunos representativos para su análisis.
4.1 Serie ZK
Incluyendo, entre otros, Sovereign Labs, Fractal, StarkNet, Opside, ZKsync
StarkWare: L3 personalizado basado en ZKRollup
Refiriéndose al gráfico anterior, el equipo de StarkWare propuso por primera vez el diseño de la red multicapa de Ethereum en el artículo "Fractal Scaling: From L2 to L3". Sin embargo, la introducción de redes multicapa no es solo para una mayor expansión, sino más bien para permitir a los propietarios de proyectos controlar más recursos de la cadena al apilar paquetes acumulativos personalizados sobre la base del escalamiento de propósito general L2, brindando una experiencia de usuario que el paquete acumulativo L2 no puede alcanzar. .
Aunque desde un punto de vista computacional, se puede generar un ZKP para un grupo de ZKP para demostrar su validez, pero los datos no se pueden comprimir y luego comprimir más. Debido a que se debe garantizar la disponibilidad de los datos, permitiendo que cualquiera pueda verificar la validez de la prueba, el resumen debe enviar el contenido completo o comprimido de la transacción a L1.
Por lo tanto, los escenarios de aplicación de la cadena de aplicaciones específicas de StarkWare deben buscar un alto rendimiento o características específicas.
Alto rendimiento: los juegos que exigen un alto rendimiento pueden utilizar exclusivamente recursos del circuito ZK para brindar una mejor experiencia de usuario;
Privacidad: para algunos proyectos con necesidades de privacidad, las funciones de privacidad se pueden implementar de forma personalizada además del resumen o el resumen del resumen;
Ampliación de la compatibilidad: proporcionar un entorno compatible con EVM, o incluso compatibilidad con más lenguajes de programación, aporta un valor positivo al ecosistema mismo;
Bajo costo: Reduzca en gran medida los costos operativos al sacrificar cierto grado de descentralización y seguridad a través de Validium.
En teoría, la solución L3 basada en Validium de StarkNet puede reducir costos de manera intuitiva y también garantiza la interoperabilidad.
Sin embargo, desde la perspectiva de la personalización, se puede inferir además que esta cadena específica de aplicaciones basada en ZKrollup, si bien proporciona una mejora considerable del rendimiento, también eleva el costo de desarrollo y el umbral de participación para las partes del proyecto. Por lo tanto, los proveedores de RaaS deben estar profundamente involucrados en el desarrollo y la velocidad y escala de expansión en el proceso de comercialización son limitadas.
Lo contrario: otra estructura de red de tres capas diseñada para cadenas específicas de aplicaciones
Consulte el diagrama a continuación, en comparación con StarkWare, el diseño L3 específico de la aplicación basada en el paquete acumulativo L2 de ZKsync, Opside propone una red de tres capas diseñada específicamente para aplicaciones de alto TPS. Diseña una cadena lateral como L2 basada en un consenso PoS+PoW y conecta la cadena específica de la aplicación como L3 a la cadena lateral.
Opside interactúa con los datos a través del puente ZK que ha desarrollado y, a diferencia de las cadenas laterales tradicionales, la prueba de legalidad se completa a través de zkp en lugar de firma múltiple, por lo que tiene mayor seguridad. Mientras tanto, Opside integra el rollup específico de la aplicación en el consenso de la cadena lateral L2 a través del rollup nativo, es decir, motiva a terceros a mantener el rollup en la cadena lateral L2 desde la perspectiva del consenso.
La interoperabilidad es crucial para RaaS, y los paquetes acumulativos nativos en Opside comparten un árbol de estado mundial y una cola de mensajes global. Por lo tanto, la interacción de activos e información entre paquetes acumulativos específicos de aplicaciones será muy eficiente y costará menos. La interacción de activos entre cadenas solo necesita llamar directamente al método de contrato de la acumulación de destino en un contrato de acumulación L3. Sin embargo, la compatibilidad y el desarrollo del ecosistema siguen siendo un desafío para los paquetes acumulativos basados en ZK.
La desventaja que conlleva el tiempo de finalidad más rápido y sin confianza de ZK es que la escala comercial de RaaS está limitada por la potencia informática, lo que requiere soporte de hardware para generar ZKP, lo que también es una de las razones por las que la mayoría de RaaS no adoptan ZK. Además, el diseño de la cadena lateral como L2 plantea un desafío para la seguridad de los proveedores de RaaS.
4.2 Serie optimista
Incluyendo, entre otros, Caldera, Eclipse
Caldera: Maximización de la experiencia del usuario basada en Op Stack
Caldera es un RaaS basado en pila operativa, que proporciona a los equipos de proyectos alto rendimiento, baja latencia y funcionalidades personalizables de acumulación L2. Su testnet actual permite a cualquiera crear un paquete acumulativo L2 en muy poco tiempo. La experiencia del usuario es muy fluida; puedes probarlo aquí: https://dashboard.caldera.xyz/
El diseño basado en la pila Op le da a Caldera una gran ventaja en compatibilidad. Con total compatibilidad con EVM y la optimización de la experiencia del usuario por parte del equipo, reduce significativamente las barreras para la migración/desarrollo. Además, RaaS de Caldera no está limitado por la potencia informática del hardware subyacente, lo que permite que más equipos de proyectos se implementen rápidamente, construyendo así un ecosistema más próspero.
Con referencia al diagrama estructural en la documentación oficial de Caldera, Caldera Chains no solo puede lanzar un paquete acumulativo de L2 como servicio en Ethereum, sino que también puede proporcionar servicios en cualquier L1 compatible con EVM, garantizando la validez de las transacciones mediante el envío de pruebas de fraude a L1. En la capa de disponibilidad de datos, Caldera también realizó innovaciones, desvinculando la capa de disponibilidad de datos de la capa de liquidación. Los paquetes acumulativos personalizados pueden enviar contenidos de transacciones a Ethereum o a una capa DA dedicada, como Eigenlayer o Celestia. Este diseño optimiza en mayor medida la escalabilidad y los costos de transacción de Caldera.
La interoperabilidad del ecosistema de Caldera se logra mediante el puente interno de cadenas cruzadas. Permite activos y datos entre cadenas mediante la implementación de contratos en los paquetes acumulativos L1 correspondientes y específicos de la aplicación. Mientras tanto, Caldera también proporciona un SDK de JavaScript de alto nivel para ayudar a los desarrolladores a agregar de manera más eficiente funciones entre cadenas en paquetes acumulativos personalizados.
Aunque Caldera ha hecho mucho en interoperabilidad y puentes entre cadenas, los paquetes acumulativos optimistas requieren un tiempo a prueba de fraude de 7 días, lo que convierte en un desafío construir interoperabilidad entre paquetes acumulativos. Al mismo tiempo, un RaaS optimista no puede lograr la falta de confianza; uno debe confiar en que existe al menos un retador para evitar que el secuenciador se comporte mal.
Además, en personalización, Caldera y otros Optimistic RaaS se centran más en bajo costo y alto TPS, y es difícil aportar tanto valor en funcionalidad y rendimiento a los proyectos como RaaS basado en ZK. Si observamos los actuales paquetes acumulativos de escalamiento de propósito general, pueden lograr un tiempo de bloqueo, tps y costos de transacción bastante considerables. Los datos y RaaS no son significativamente diferentes, lo que indica una mejora de 0 a 1. Por lo tanto, vale la pena preguntarse si las mejoras de costos y rendimiento aportadas por RaaS basado en operaciones son lo que necesita el mercado actual.
4.3 Cadena de bloques modular
Incluyendo, entre otros, Celestia, Dymension
Celestia: construcción de una cadena de bloques modular basada en la capa DA
Celestia es esencialmente una capa de disponibilidad de datos. Se construye una arquitectura jerárquica de blockchain escalable sobre una capa DA basada en el consenso de Tendermint. A través de rollmint (un tipo de implementación de interfaz de cadena de bloques de aplicaciones), las dapps pueden crear su paquete acumulativo e implementarlo en Celestia, con los datos almacenados en la capa DA y la raíz del estado y la prueba cargada en L1 para su verificación. Celestia optimiza la capa DA mediante muestreo de disponibilidad de datos (DAS), donde cada nodo ligero de la red solo necesita muestrear y descargar una pequeña porción de datos del bloque. Por lo tanto, cuantos más nodos, más transacciones puede contener cada bloque, logrando el propósito de escalar la capa DA.
Esto nos recuerda a los familiares Validiums: una solución de escalabilidad que verifica los resultados de los cálculos utilizando algoritmos ZK, no carga datos en L1 y depende de validadores para la custodia de los datos. Dado que los datos existen fuera de la cadena en lugar de publicarse directamente en la Capa 1, Validium reduce los costos de gas. Sin embargo, desde la perspectiva de la descentralización y la seguridad, la disponibilidad de datos depende de un comité de terceros, por lo que los Validiums no se utilizan ampliamente.
Desde la perspectiva de la implementación, las dapps en todo el ecosistema están esencialmente construyendo su Validium, manteniendo el secuenciador y el probador, y Celestia proporciona un espacio de almacenamiento de datos unificado. Al igual que Validiums, este método de implementación reduce el costo operativo de las dapps pero también sacrifica cierto grado de descentralización y seguridad. En comparación con otras soluciones que heredan la seguridad de Ethereum, la seguridad de las cadenas dapp en Celestia depende de los nodos y la capa DA.
Además, Celestia actualmente no admite sistemas a prueba de fraude. Por lo tanto, los nodos deben volver a ejecutar todas las transacciones basándose en una suposición pesimista para garantizar su validez. Al mismo tiempo, rollmint solo admite un único secuenciador, lo que deja mucho margen de mejora en términos de eficiencia y descentralización.
Sin embargo, como capa DA, el potencial de Celestia se extiende mucho más allá de esto. Por ejemplo, la optimista solución RaaS Eclipse utiliza Celestia como su capa de consenso y DA.
5. Conclusión y perspectivas
RaaS puede aportar intuitivamente mejoras en el costo y el rendimiento, pero, a partir del rendimiento, estas optimizaciones no tienen un gran atractivo; Aún es necesario vincular un mayor valor a las funciones personalizadas. Actualmente, la demanda del mercado es limitada, pero con el desarrollo futuro de las criptomonedas, un mayor tráfico conducirá a un aumento lineal en la búsqueda de bajo costo y alto rendimiento por parte de dapp, y los servicios acumulativos personalizados son claramente una solución viable.
Para responder a la pregunta planteada al principio, ¿cuál es mi comprensión de la forma definitiva de RaaS? ¿Qué tipo de RaaS conquistará el mercado?
Del producto mismo
La ventaja de RaaS basado en OP radica en la rápida construcción de un ecosistema y la formación de barreras, pero las mejoras menores aportadas únicamente por el costo y la eficiencia no son suficientes para atraer proyectos, por lo que no hay valor a largo plazo. Por otro lado, RaaS basado en ZK puede resolver los problemas con funciones personalizadas, pero la demanda aún no es generalizada.
El diseño de una estructura de red multicapa permite que L3 RaaS tenga costos más bajos y una interoperabilidad más sólida. Además, una sólida interoperabilidad es la base para construir un ecosistema RaaS próspero. Por lo tanto, un diseño de red multicapa basado en ZK puede combinar las ventajas de la personalización y el bajo costo, y podemos ver su valor a largo plazo.
Creo que, a largo plazo, la red RaaS multicapa basada en ZK se convertirá en la mejor opción del mercado.
Mercado y demanda
Un RaaS con suficiente escalabilidad puede satisfacer las necesidades de todos los proyectos de paquetes acumulativos personalizados y al mismo tiempo garantizar el rendimiento. Al mismo tiempo, el aumento real de RaaS depende en gran medida de la construcción del ecosistema. Por lo tanto, un patrón en el que coexisten múltiples RaaS claramente no tiene sentido.
Creo que el final definitivamente será que uno o muy pocos RaaS dominen todo el mercado.
Referencia
https://ethresear.ch/t/rollup-as-a-service-opportunities-and-challenges/13051
https://ibcprotocol.org/
https://messari.io/report/the-rollups-as-a-service-ecosystem
Acerca de las empresas de previsión
Foresight Ventures se dedica a respaldar la innovación disruptiva de blockchain durante las próximas décadas. Gestionamos múltiples fondos: un fondo de capital de riesgo, un fondo secundario de gestión activa, un FOF de múltiples estrategias y un fondo secundario de mercado privado, con activos gestionados que superan los 400 millones de dólares. Foresight Ventures se adhiere a la creencia de una “mentalidad única, independiente, agresiva y a largo plazo” y brinda un amplio apoyo a las empresas de cartera dentro de un ecosistema en crecimiento. Nuestro equipo está compuesto por veteranos de las principales empresas financieras y tecnológicas como Sequoia Capital, CICC, Google, Bitmain y muchas otras.
Sitio web: https://www.foresightventures.com/
Descargo de responsabilidad: Todos los artículos de Foresight Ventures no pretenden ser consejos de inversión. Las personas deben evaluar su propia tolerancia al riesgo y tomar decisiones de inversión con prudencia.
