Scroll 联创：ETH坊生态发展的“鸡与蛋”难题

2024-12-27 08:50:49

Autor: Ye Zhang Fuente: X, @yezhang1998 Traducción: Shanooba, Golden Finance

Para Ethereum, el desarrollo lento es una característica, no una falla. Para una capa de liquidación que garantiza trillones de dólares en activos, un desarrollo demasiado rápido es peligroso.

La diversidad de clientes es importante, pero estoy de acuerdo en que tal vez necesitemos menos equipos de clientes. Además, no creo que la coordinación del equipo de clientes sea el principal cuello de botella para desarrollar nuevas funciones; hay muchos otros factores a considerar, especialmente en términos de compatibilidad hacia atrás.

Quiero plantear aquí otros tres puntos:

1. La infraestructura debe adaptarse más rápidamente a los cambios de Layer 2, de lo contrario, existe el riesgo de perder atractivo para el ecosistema de Ethereum en general.

La gente espera en general que las soluciones de Layer 2 se desarrollen más rápidamente. Sin embargo, esto es un desafío ya que muchas infraestructuras se adaptan lentamente. Incluso si Scroll es totalmente compatible con EVM, también nos encontramos con problemas en MetaMask:

Los costos de transacción de Scroll (o cualquier otra capa 2) incluyen los costos de disponibilidad de datos (DA) y los costos de ejecución, pero MetaMask solo admite los costos de ejecución de forma predeterminada, lo que ha resultado en cálculos de costos incorrectos durante varios meses.

Esto plantea un dilema complicado de qué fue primero, el huevo o la gallina:

Si Layer 1 no cambia, los proveedores de infraestructura no tienen incentivos para actualizar. Sin infraestructura actualizada, las soluciones de Layer 2 no pueden desarrollarse más rápido, lo que sofoca la innovación. Esto representa un desafío especial para Ethereum, ya que la mayoría de las demás cadenas tienen billeteras nativas estrechamente relacionadas con las actualizaciones de la cadena. En comparación, el estándar EVM sigue Ethereum, lo que hace que la adaptación sea más compleja.

2. Es crucial tener normativas, y actualmente todas las soluciones de Capa 2 carecen de normativas

Para lograr la diversidad de clientes, necesitamos una especificación más completa. Sin embargo, muchos equipos afirman tener implementaciones de múltiples clientes, pero en realidad tienen una comprensión fundamentalmente errónea de este concepto.

La forma correcta de hacerlo debería ser:

Definir especificaciones de alto nivel.
Asegurarse de que cualquier equipo pueda implementar esta función leyendo las especificaciones sin tener que consultar otra implementación del cliente.

Es decir, la única fuente real de implementación multi-cliente debería ser la especificación en sí misma. Sin embargo, en la actualidad, la mayoría de las implementaciones dependen de implementaciones existentes como referencia, lo que va en contra del verdadero potencial de la arquitectura multi-cliente.

3. También es importante tener en cuenta las diferencias entre Ethereum y Bitcoin

El Bitcoin depende de una implementación única como su fuente real, la biblioteca de código principal es la única verdad y no puede haber errores.

Y la verdadera fuente de Ethereum es la propia especificación, no una implementación específica como Geth.

Este método hace que la estandarización tenga más sentido para Ethereum. Si ocurre un error, debe corregirse según el consenso social según la especificación, en lugar de depender de una implementación específica.

SCR2,54%

ETH-0,56%

X-3%

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.