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

Autor: Ye Zhang Fonte: X, @yezhang1998 Tradução: Shanooba, Golden Finance

Para o Ethereum, o desenvolvimento lento é uma característica, não uma falha. Para uma camada de resolução que protege trilhões de dólares em ativos, um desenvolvimento rápido é perigoso.

A diversidade dos clientes é importante, mas concordo que podemos realmente precisar de menos equipas de clientes. Além disso, não acho que a coordenação da equipe do cliente seja o principal gargalo no desenvolvimento de novas funcionalidades; Há muitos outros fatores a considerar, especialmente quando se trata de compatibilidade com versões anteriores.

Eu gostaria de apresentar mais três pontos aqui:

1. A infraestrutura precisa de se adaptar mais rapidamente às mudanças da Camada 2, caso contrário, há um risco de o ecossistema Ethereum como um todo perder a sua atratividade.

As pessoas geralmente esperam que as soluções Layer 2 se desenvolvam mais rapidamente. No entanto, isso é desafiador porque muitas infraestruturas têm uma velocidade de adaptação lenta. Mesmo que o Scroll seja totalmente compatível com a EVM, ainda enfrentamos problemas com o MetaMask:

O custo de transação do Scroll (ou qualquer outro Layer 2) inclui a taxa de Disponibilidade de Dados (DA) e a taxa de execução, mas o MetaMask só suporta por padrão a taxa de execução, resultando em cálculos incorretos de taxas nos últimos meses.

Isto levanta a complicada questão de qual veio primeiro, o ovo ou a galinha:

Se a camada 1 não mudar, os provedores de infraestrutura não terão incentivo para atualizar. Sem uma infraestrutura atualizada, as soluções de camada 2 não podem se desenvolver mais rapidamente, o que sufoca a inovação. Isso é um desafio especial para o Ethereum, porque a maioria das outras cadeias tem uma carteira nativa intimamente relacionada à atualização da cadeia. Em contraste, o EVM segue o padrão Ethereum, o que torna a adaptação mais complexa.

2. A padronização é crucial, e atualmente todas as soluções de Camada 2 carecem de padronização

Para alcançar a diversidade do cliente, precisamos de regulamentações mais abrangentes. No entanto, muitas equipes afirmam ter implementações de vários clientes, mas na realidade, há um mal-entendido fundamental sobre este conceito.

A maneira correta de fazer as coisas deve ser:

Definir especificações de alto nível.
Assegurar que qualquer equipe possa implementar essa funcionalidade lendo a especificação, sem precisar consultar outra implementação do cliente.

Em outras palavras, a única fonte verdadeira de uma implementação multi-cliente deve ser a especificação em si. No entanto, atualmente, a maioria das implementações depende de implementações existentes como referência, o que vai contra o verdadeiro potencial da arquitetura multi-cliente.

3. Também é importante notar a diferença entre Ethereum e Bitcoin

O Bitcoin depende de uma implementação única como sua verdadeira origem, a base de código central é a única verdade e não pode estar errada.

A verdadeira fonte do Ethereum é a própria especificação, e não uma implementação específica como o Geth.

Este método torna as especificações do Ethereum mais significativas. Em caso de erro, o problema deve ser corrigido de acordo com o consenso social e as especificações, em vez de depender de uma implementação específica.