Desde los puentes entre cadenas hasta L2, ¿cuáles son las consideraciones estratégicas para la transformación de Orbiter?

Recientemente, Tiger Research publicó un informe de investigación en profundidad sobre el puente de cadena cruzada Orbiter Finance, enumerando sus datos de participación de mercado ultra alta en la cadena cruzada de activos de capa 2 convencionales, y mencionó que Orbiter está realizando una transformación estratégica de un puente de cadena cruzada a una cadena de capa 2 de Vizing. La pregunta es, si el “modelo de negocio” de los puentes entre cadenas no es malo, ¿por qué deberíamos ser ambiciosos para construir cadenas de capa 2? Vamos, déjame tratar de descifrar:

1. Desde que Ethereum estableció la estrategia de expansión de la capa 2 centrada en el rollup, el “puente entre cadenas” se ha convertido en una prioridad como servicio de componentes clave que conecta la comunicación de mensajes de la capa 2 y la interoperabilidad de activos.

Sin embargo, debido al hecho de que la ruta original de la cadena cruzada definida por Ethereum es básicamente L2 - > L1 - > L2, más la ventana de tiempo de desafío de 7 días de OP-Rollup, si la cadena de capa 2 A quiere transferir un activo a la cadena de capa 2 B, además de las 2 grandes tarifas de gas de cadena cruzada entre la red principal y la capa 2 para soportar, también hay un costo de tiempo más largo para bloquear fondos.

Como resultado, la mayoría de los activos de cadena cruzada entre capas 2 se basan en las soluciones de retiro centralizado de los CEX centralizados o en protocolos de puente entre cadenas de terceros como Orbiter, Hop Protocol y Wormhole.

Es por eso que, como se indica en el informe, Orbiter Finance ha podido mantenerse a la vanguardia en esta ronda de expansión de capa 2, con una participación de mercado de aproximadamente el 40% y un mecanismo Maker único, con una empresa que representa casi el 70% de las ganancias en el mercado de puentes entre cadenas. Estos datos pueden confirmar el éxito de Orbiter en la pista del puente entre cadenas.

2. Sin embargo, después de la actualización de Cancún, el mercado de capas 2 mostró una vez una situación de cien flores, y los dos campos dominados por OP-Rollup y ZK-Rollup continuaron expandiéndose verticalmente, promoviendo constantemente sus propias pilas de tecnología y ecosistemas, por ejemplo, OP Stack ha desarrollado docenas de nuevas capas 2, incluida Base como parte de su gran estrategia Superchain.

Sin embargo, tanto OP Stack como ZK Stack están enterrando la cabeza en el desarrollo de sus respectivos ecosistemas cerrados, y aunque sus alas se están llenando gradualmente, muestran cada vez más una tendencia al desarrollo de la separación principesca, lo que conduce a una mayor dispersión de la liquidez de la capa 2 y a la fragmentación constante de la experiencia del usuario.

En este caso, @VitalikButerin ha pedido repetidamente la capa 2 para mejorar la interoperabilidad, y lanzó el cliente ligero Helios para acelerar la falta de confianza y la interoperabilidad entre las capas 2. Además, muchas abstracciones de la cadena, incluidas @ParticleNtwrk y @ProjectZKM, y los proveedores de servicios técnicos de ZK también han intervenido a través de la capa interoperable de terceros para ayudar a unificar la liquidez del ecosistema de capa 2 de Ethereum.

Esto significa que el Endgame del ecosistema de capa 2 de Ethereum construirá definitivamente una capa interoperable consistente, lo que significa que si los puentes entre cadenas como Orbiter están satisfechos con el “modelo de negocio” actual, eventualmente pueden enfrentar el riesgo de ser eliminados del mercado.

3. Por lo tanto, no es difícil entender por qué Orbiter ha cambiado de pasivo a activo y ha lanzado la solución de extensión de capa 2 de Vizing para permitir una interacción de activos segura y de bajo costo entre cadenas múltiples de capa 2.

Como se mencionó anteriormente, la otra capa 2 son las estrategias de desarrollo de los príncipes, y frente a Vizing, me temo que solo hay un camino a seguir. Con este fin, la cadena Vizing se construye con tres características principales:

1. Vizing Account Abstraction (VAA): permite a los usuarios administrar múltiples redes de capa 2 con una sola cuenta, lo que simplifica enormemente la experiencia del usuario, similar al servicio de abstracción de cuenta unificado proporcionado por el servicio de abstracción en cadena;

2. Vizing Environment Layer (VEL): Proporcione a los desarrolladores un entorno de desarrollo unificado entre cadenas y reduzca el umbral para la construcción ecológica, que es equivalente a un estándar unificado de comunicación entre cadenas.

3. Comunicación de información entre cadenas entre Rollups: Para reducir la dependencia de Ethereum L1, es necesario adaptarse a diferentes cadenas de Rollups de capa 2 y utilizar una interfaz unificada y estandarizada para transmitir e intercambiar información con ellas, a fin de proporcionar condiciones para un intercambio de activos eficiente y descentralizado entre empresas de capa 2.

Encima.

En general, bajo la premisa de que la capa 2 se moverá inevitablemente hacia la interoperabilidad y unificación entre cadenas, Orbiter opta por tomar la iniciativa para “revolucionarse” a sí mismo y promover una estrategia de capas compartidas interoperables de capa 2 más ambiciosa e imaginativa.

Además, con el establecimiento de hojas de ruta posteriores, como los posteriores ZK-SNARK del ecosistema Ethereum, incluido el esperado plan de actualización de la red Beam Chain, etc., todos apuntan a un ecosistema unificado de interoperabilidad de capa 2.