Autor: Neel Somani, fundador de Eclipse, ex investigador cuantitativo en Citadel; traducción: Jinse Finance xiaozou
En Eclipse, estamos creando una infraestructura de acumulación específica de aplicaciones personalizable para admitir verticales como Gaming & Social, DePIN y DeFi.
Hemos estado trabajando en esto durante 10 meses más o menos, y siento la necesidad de aclarar algunos conceptos erróneos. Estas son algunas ideas sobre los paquetes acumulativos específicos de la aplicación:
1. La división de mercado existente es incorrecta
**(1)**El marco acumulativo no es una organización benéfica
Los marcos de resumen como OP Stack son bases de código que implementan componentes clave de los paquetes acumulativos. No le cobrarán por el uso del código, pero necesitan capturar valor de alguna manera. Para resumir, hay tres lugares donde se puede obtener valor:
Ejecución: ordenación de transacciones, ejecución y pruebas (zk-rollup)
Liquidación: puentear y verificar pruebas de validez o pruebas de error
· Disponibilidad de datos: Publicar orden de transacción
Pero solo la ejecución es adecuada como modelo de negocio para el marco de trabajo acumulativo:
Liquidación: después de la actualización de Bedrock, Optimism solo paga a Ethereum una tarifa de liquidación de alrededor de $5 por día. El resto de los gastos generales de OP Stack proviene de la emisión de bloques y las tarifas relacionadas. Los protocolos de liquidación de la competencia pueden ganar incluso menos.
Disponibilidad de datos: las capas de DA fragmentadas son menos riesgosas para proteger la red que las capas de disponibilidad de datos (DA) compartidas, como Celestia. Muchos rollups no quieren migrar su DA fuera de Ethereum porque eso sacrificaría su consistencia con Ethereum.
Cualquier segmento de mercado debe incluir marcos de resumen en al menos una categoría relacionada con la ejecución, y cualquier producto que brinde servicios de ejecución puede competir con los marcos de resumen.
(2) La acumulación aislada como servicio (RaaS) es insostenible
La explicación ingenua para RaaS es en realidad secuenciador aislado como servicio (iSaaS). Estas empresas no tienen su propio protocolo, pero están implementando un marco acumulativo de código abierto existente y ejecutando un secuenciador. OP Stack tiene una asociación con iSaaS.
El modelo comercial de iSaaS consiste en cobrar algunas tarifas legales recurrentes además de cobrar un porcentaje de la tarifa del secuenciador. (Los servicios de soporte adicionales, la consultoría o el desarrollo de funciones personalizadas no representan un modelo comercial escalable). imperfecciones fatales.
Un gran problema con iSaaS es que no se alinea con el marco de trabajo acumulativo. Como se mencionó anteriormente, un marco de acumulación optimista como OP Stack tiene que monetizar las tarifas del clasificador. (Un marco zk-rollup podría ignorar la tarifa del ordenante y solo mantener la tarifa del probador).
Otros problemas de alto nivel con este tipo de negocio son que está mercantilizado, es fácil de ingresar y no tiene efectos de red, a diferencia de un pedido compartido. iSaaS carece de las economías de escala de los secuenciadores compartidos porque cada secuenciador está aislado.
(3)Op****timistael marco acumulativo debe proporcionar su propio S****aaS
Para tener un buen desempeño, iSaaS puede devolver las tarifas del secuenciador a un marco de acumulación optimista, dejando solo tarifas fiduciarias recurrentes.
Pero ahora, tanto iSaaS como los marcos de consolidación deben ser rentables de forma independiente. Los precios ideales para las grandes empresas serían pagos fiduciarios recurrentes altos, pero tarifas bajas para los pedidos. Sin embargo, iSaaS no tiene la flexibilidad para reducir la tarifa del pedido, porque la tarifa del pedido no les pertenece originalmente, sino que se transfiere al marco de acumulación. Si el iSaaS no comparte los ingresos con el marco de consolidación, el marco de consolidación puede implementar su propio iSaaS y, dado que la confianza ya está establecida, puede penetrar en el mercado más profundamente.
La razón por la que aparecen tantos iSaaS es porque parece atractivo para los lectores menos experimentados. Parece SaaS, por lo que a los inversores que no son criptográficos les puede resultar más fácil extrapolar los ingresos fiduciarios. Pero iSaaS tendrá dificultades para competir con los marcos acumulativos que tienen su propio SaaS con tokens e ingresos nativos del protocolo. Este último tiene más opciones en términos de precios, los tokens se pueden usar para subsidiar proyectos prometedores, subsidiar los costos de adquisición de clientes y los costos fijos de funcionamiento (discutidos a continuación).
Los efectos de red nativos del protocolo y los costos fijos compartidos crearán una economía unitaria más sólida para los protocolos con mayor visibilidad, lo que hará que los proveedores de rollup se queden con todo.
(4) MAPA DE MERCADO AJUSTADO
Ahora puedo mostrar cómo ajusté los gráficos en el artículo de Messari, que pensé que parecía razonable en ese momento:
(Gráfico de mercado de Messari)
(Gráfico de mercado ajustado)
Voy a cambiar el nombre de la categoría "Sin implementación de código" y el SDK de resumen a Marcos de resumen porque muchos marcos de resumen no proporcionan un SDK completo a los desarrolladores. También me gustaría modificar este diagrama del ecosistema de Celestia:
(Diagrama del Ecosistema de Celestia)
(Diagrama del ecosistema de Celestia ajustado)
Eliminaré RaaS, la capa de facturación y las máquinas virtuales. Para los proyectos de la categoría Marco acumulativo, es casi seguro que también se encontrarán en otra categoría, o no serán rentables.
2. No hay almuerzo gratis: restricciones económicas y técnicas
(1) La mayoría de las aplicaciones no deberían tener su propio resumen
La forma más fácil de demostrar la economía de un paquete acumulativo para una aplicación específica es observar los paquetes acumulativos en vivo: Optimismo (después de la actualización de Bedrock). Este es el enfoque que tomó el equipo de Optimism para hacer el tablero de Dune.
Lo siguiente asume que el precio del gas en Ethereum es de aproximadamente 25 gwei:
· El costo único de implementación de la cadena de red principal OP Stack es de aproximadamente 1 ETH
· El costo fijo de la cadena OP Stack (incluso si el número de transacciones en ejecución es 0) es de aproximadamente 0,5 ETH por día
· El costo variable es de 7.5 * 10^-5 ETH por transacción
Para obtener el costo fijo, multipliqué el costo general promedio por transacción por la cantidad de transacciones que se ejecutan ese día y lo confirmé ejecutando la cadena OP Stack en la red principal.
Este costo variable es bajo, pero no al nivel de Solana, y el costo fijo puede amortizarse en muchas transacciones. En un futuro EIP-4844, podemos asumir bastante bien que este costo se reduce en un factor de 10. Aún así, digamos que un precio ETH de $ 2000 representa un piso de $ 0.015 por transacción más algunos costos fijos amortizados.
Podríamos considerar 0.00001 ETH (aproximadamente $0.02 en el momento de escribir este artículo) como un token de transacción razonable para cubrir este costo fijo, por lo que necesitaríamos 50 000 transacciones por día para que un paquete acumulativo de aplicaciones en particular valga la pena. Antes de EIP-4844, costaba alrededor de $0,17 por transacción y, de manera optimista, después de EIP-4844, era de $0,03 por transacción. Podemos agregar una pequeña prima, por lo que la cadena de respaldo del clasificador (compartido) es económica.
Entonces, si bien algo como Opclave es genial (realmente me gusta la idea, estamos hablando con el equipo de Dogan para que podamos incorporar esta funcionalidad en el resumen de Eclipse), no tiene mucho sentido como una cadena OP Stack de mainnet. La restricción aquí es que la cadena OP Stack está anclada en Ethereum, cuyo espacio de bloques es costoso, y la intención de Optimism es ser consistente con Ethereum.
Dada esta economía unitaria, esos pequeños proyectos DeFi dApps y NFT no tienen mucho sentido en sus propias cadenas. Para estas dApps, podría tener sentido subsidiar los costos de gasolina si la economía unitaria a largo plazo de Ethereum L2 tiene sentido para sus dApps, o podrían estar dispuestos a asumir la pérdida en su cadena de aplicaciones.
Si una aplicación requiere demasiado volumen de transacciones, un paquete acumulado vinculado a Ethereum tampoco funcionará, ya que las tarifas de transacción de más de $ 0.01 pueden ser demasiado altas. Estos tipos de aplicaciones requerirán un enfoque novedoso, como el que Eclipse está construyendo con nuestras máquinas virtuales altamente paralelas y arquitectura de acumulación soberana.
(2) El resumen personalizable debe estar restringido
Como se mencionó anteriormente, OP Hacks no se incluirán en Optimism's Superchain. Esto tiene sentido porque para liquidar correctamente o proporcionar ordenamiento estatal para acumulaciones, necesitamos que algunas invariantes sean verdaderas. Cualquier modificación deberá ser auditada antes de respaldar el valor económico real.
Otra buena razón para restringir los paquetes acumulativos específicos de la aplicación es observar la adopción de Cosmos. El SDK de Cosmos es muy general, pero nunca provocó la gran cantidad de cadenas diferentes que cabría esperar. Esto puede deberse a que el proceso de personalización requiere demasiada complejidad técnica o, más probablemente, a que la larga cola de la aplicación se adapta bien a un pequeño número de arquitecturas. Las plantillas específicas de dominio, por otro lado, pueden abordar puntos débiles comunes en diferentes verticales y proporcionar una arquitectura repetible.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Fundador de Eclipse: algunos malentendidos sobre RaaS
Autor: Neel Somani, fundador de Eclipse, ex investigador cuantitativo en Citadel; traducción: Jinse Finance xiaozou
En Eclipse, estamos creando una infraestructura de acumulación específica de aplicaciones personalizable para admitir verticales como Gaming & Social, DePIN y DeFi.
Hemos estado trabajando en esto durante 10 meses más o menos, y siento la necesidad de aclarar algunos conceptos erróneos. Estas son algunas ideas sobre los paquetes acumulativos específicos de la aplicación:
1. La división de mercado existente es incorrecta
**(1)**El marco acumulativo no es una organización benéfica
Los marcos de resumen como OP Stack son bases de código que implementan componentes clave de los paquetes acumulativos. No le cobrarán por el uso del código, pero necesitan capturar valor de alguna manera. Para resumir, hay tres lugares donde se puede obtener valor:
Ejecución: ordenación de transacciones, ejecución y pruebas (zk-rollup)
Liquidación: puentear y verificar pruebas de validez o pruebas de error
· Disponibilidad de datos: Publicar orden de transacción
Pero solo la ejecución es adecuada como modelo de negocio para el marco de trabajo acumulativo:
Liquidación: después de la actualización de Bedrock, Optimism solo paga a Ethereum una tarifa de liquidación de alrededor de $5 por día. El resto de los gastos generales de OP Stack proviene de la emisión de bloques y las tarifas relacionadas. Los protocolos de liquidación de la competencia pueden ganar incluso menos.
Disponibilidad de datos: las capas de DA fragmentadas son menos riesgosas para proteger la red que las capas de disponibilidad de datos (DA) compartidas, como Celestia. Muchos rollups no quieren migrar su DA fuera de Ethereum porque eso sacrificaría su consistencia con Ethereum.
Cualquier segmento de mercado debe incluir marcos de resumen en al menos una categoría relacionada con la ejecución, y cualquier producto que brinde servicios de ejecución puede competir con los marcos de resumen.
(2) La acumulación aislada como servicio (RaaS) es insostenible
La explicación ingenua para RaaS es en realidad secuenciador aislado como servicio (iSaaS). Estas empresas no tienen su propio protocolo, pero están implementando un marco acumulativo de código abierto existente y ejecutando un secuenciador. OP Stack tiene una asociación con iSaaS.
El modelo comercial de iSaaS consiste en cobrar algunas tarifas legales recurrentes además de cobrar un porcentaje de la tarifa del secuenciador. (Los servicios de soporte adicionales, la consultoría o el desarrollo de funciones personalizadas no representan un modelo comercial escalable). imperfecciones fatales.
Un gran problema con iSaaS es que no se alinea con el marco de trabajo acumulativo. Como se mencionó anteriormente, un marco de acumulación optimista como OP Stack tiene que monetizar las tarifas del clasificador. (Un marco zk-rollup podría ignorar la tarifa del ordenante y solo mantener la tarifa del probador).
Otros problemas de alto nivel con este tipo de negocio son que está mercantilizado, es fácil de ingresar y no tiene efectos de red, a diferencia de un pedido compartido. iSaaS carece de las economías de escala de los secuenciadores compartidos porque cada secuenciador está aislado.
(3)Op****timista el marco acumulativo debe proporcionar su propio S****aaS
Para tener un buen desempeño, iSaaS puede devolver las tarifas del secuenciador a un marco de acumulación optimista, dejando solo tarifas fiduciarias recurrentes.
Pero ahora, tanto iSaaS como los marcos de consolidación deben ser rentables de forma independiente. Los precios ideales para las grandes empresas serían pagos fiduciarios recurrentes altos, pero tarifas bajas para los pedidos. Sin embargo, iSaaS no tiene la flexibilidad para reducir la tarifa del pedido, porque la tarifa del pedido no les pertenece originalmente, sino que se transfiere al marco de acumulación. Si el iSaaS no comparte los ingresos con el marco de consolidación, el marco de consolidación puede implementar su propio iSaaS y, dado que la confianza ya está establecida, puede penetrar en el mercado más profundamente.
La razón por la que aparecen tantos iSaaS es porque parece atractivo para los lectores menos experimentados. Parece SaaS, por lo que a los inversores que no son criptográficos les puede resultar más fácil extrapolar los ingresos fiduciarios. Pero iSaaS tendrá dificultades para competir con los marcos acumulativos que tienen su propio SaaS con tokens e ingresos nativos del protocolo. Este último tiene más opciones en términos de precios, los tokens se pueden usar para subsidiar proyectos prometedores, subsidiar los costos de adquisición de clientes y los costos fijos de funcionamiento (discutidos a continuación).
Los efectos de red nativos del protocolo y los costos fijos compartidos crearán una economía unitaria más sólida para los protocolos con mayor visibilidad, lo que hará que los proveedores de rollup se queden con todo.
(4) MAPA DE MERCADO AJUSTADO
Ahora puedo mostrar cómo ajusté los gráficos en el artículo de Messari, que pensé que parecía razonable en ese momento:
(Gráfico de mercado de Messari)
(Gráfico de mercado ajustado)
Voy a cambiar el nombre de la categoría "Sin implementación de código" y el SDK de resumen a Marcos de resumen porque muchos marcos de resumen no proporcionan un SDK completo a los desarrolladores. También me gustaría modificar este diagrama del ecosistema de Celestia:
(Diagrama del Ecosistema de Celestia)
(Diagrama del ecosistema de Celestia ajustado)
Eliminaré RaaS, la capa de facturación y las máquinas virtuales. Para los proyectos de la categoría Marco acumulativo, es casi seguro que también se encontrarán en otra categoría, o no serán rentables.
2. No hay almuerzo gratis: restricciones económicas y técnicas
(1) La mayoría de las aplicaciones no deberían tener su propio resumen
La forma más fácil de demostrar la economía de un paquete acumulativo para una aplicación específica es observar los paquetes acumulativos en vivo: Optimismo (después de la actualización de Bedrock). Este es el enfoque que tomó el equipo de Optimism para hacer el tablero de Dune.
Lo siguiente asume que el precio del gas en Ethereum es de aproximadamente 25 gwei:
· El costo único de implementación de la cadena de red principal OP Stack es de aproximadamente 1 ETH
· El costo fijo de la cadena OP Stack (incluso si el número de transacciones en ejecución es 0) es de aproximadamente 0,5 ETH por día
· El costo variable es de 7.5 * 10^-5 ETH por transacción
Para obtener el costo fijo, multipliqué el costo general promedio por transacción por la cantidad de transacciones que se ejecutan ese día y lo confirmé ejecutando la cadena OP Stack en la red principal.
Este costo variable es bajo, pero no al nivel de Solana, y el costo fijo puede amortizarse en muchas transacciones. En un futuro EIP-4844, podemos asumir bastante bien que este costo se reduce en un factor de 10. Aún así, digamos que un precio ETH de $ 2000 representa un piso de $ 0.015 por transacción más algunos costos fijos amortizados.
Podríamos considerar 0.00001 ETH (aproximadamente $0.02 en el momento de escribir este artículo) como un token de transacción razonable para cubrir este costo fijo, por lo que necesitaríamos 50 000 transacciones por día para que un paquete acumulativo de aplicaciones en particular valga la pena. Antes de EIP-4844, costaba alrededor de $0,17 por transacción y, de manera optimista, después de EIP-4844, era de $0,03 por transacción. Podemos agregar una pequeña prima, por lo que la cadena de respaldo del clasificador (compartido) es económica.
Entonces, si bien algo como Opclave es genial (realmente me gusta la idea, estamos hablando con el equipo de Dogan para que podamos incorporar esta funcionalidad en el resumen de Eclipse), no tiene mucho sentido como una cadena OP Stack de mainnet. La restricción aquí es que la cadena OP Stack está anclada en Ethereum, cuyo espacio de bloques es costoso, y la intención de Optimism es ser consistente con Ethereum.
Dada esta economía unitaria, esos pequeños proyectos DeFi dApps y NFT no tienen mucho sentido en sus propias cadenas. Para estas dApps, podría tener sentido subsidiar los costos de gasolina si la economía unitaria a largo plazo de Ethereum L2 tiene sentido para sus dApps, o podrían estar dispuestos a asumir la pérdida en su cadena de aplicaciones.
Si una aplicación requiere demasiado volumen de transacciones, un paquete acumulado vinculado a Ethereum tampoco funcionará, ya que las tarifas de transacción de más de $ 0.01 pueden ser demasiado altas. Estos tipos de aplicaciones requerirán un enfoque novedoso, como el que Eclipse está construyendo con nuestras máquinas virtuales altamente paralelas y arquitectura de acumulación soberana.
(2) El resumen personalizable debe estar restringido
Como se mencionó anteriormente, OP Hacks no se incluirán en Optimism's Superchain. Esto tiene sentido porque para liquidar correctamente o proporcionar ordenamiento estatal para acumulaciones, necesitamos que algunas invariantes sean verdaderas. Cualquier modificación deberá ser auditada antes de respaldar el valor económico real.
Otra buena razón para restringir los paquetes acumulativos específicos de la aplicación es observar la adopción de Cosmos. El SDK de Cosmos es muy general, pero nunca provocó la gran cantidad de cadenas diferentes que cabría esperar. Esto puede deberse a que el proceso de personalización requiere demasiada complejidad técnica o, más probablemente, a que la larga cola de la aplicación se adapta bien a un pequeño número de arquitecturas. Las plantillas específicas de dominio, por otro lado, pueden abordar puntos débiles comunes en diferentes verticales y proporcionar una arquitectura repetible.