Palestrante: Vitalik Buterin, fundador da Ethereum Compilado por: 0xxz, Golden Finance EthCC7 foi realizado recentemente em Bruxelas. O organizador convidou Vitalik, fundador da Ethereum, para fazer um discurso de abertura. É importante notar que 2024 marca o 10º aniversário do IC0 da Ethereum. Após o discurso de Vitalik, os três principais fundadores da Ethereum, Vitalik Buterin, Joseph Lubin e Gavin Wood, mais uma vez tiraram uma foto de grupo juntos para comemorar a ocasião. Este artigo é o discurso proferido por Vitalik, o fundador da Ethereum, recentemente na EthCC7, compilado pela Golden Finance 0xxz. Fortalecimento do Tópico de Fala L1: Otimizando o Ethereum para se tornar uma camada base da Camada 2 altamente confiável, confiável e sem permissão

Espectro de Visão Ethereum
Acho que há um espectro de possíveis diferentes divisões de trabalho em relação ao papel que a camada base do Ethereum pode desempenhar no ecossistema nos próximos cinco a dez anos. Você pode pensar nisso como um espectro da esquerda para a direita. No lado esquerdo do espectro, basicamente tenta ser uma camada base muito minimalista que basicamente atua apenas como um validador de prova para todos os L2. Talvez também forneça a capacidade de transferir ETH entre diferentes L2s. Mas fora isso, é basicamente isso. No lado direito do espectro, há basicamente um novo foco em dApps que rodam principalmente em L1, com L2 sendo usado apenas para algumas transações muito específicas e de alto desempenho. Existem algumas opções interessantes no meio do espectro. Coloquei Ethereum como a camada base do L2, segundo a partir da esquerda. Coloquei uma versão extrema na extrema esquerda: abandonamos completamente a parte do cliente de execução do Ethereum, mantemos apenas a parte de consenso e adicionamos alguns validadores de prova de conhecimento zero, basicamente transformando toda a camada de execução em um Rollup. Quero dizer, as opções mais extremas estão à esquerda, e à direita pode ser uma camada base, mas também tente dar mais funcionalidade ao L2. Uma ideia nessa direção é reduzir ainda mais o tempo de troca do Ethereum, atualmente de 12 segundos, possivelmente para 2 a 4 segundos. O objetivo disso é, na verdade, tornar viáveis ​​​​os rollups baseados como a principal forma de operação L2. Portanto, agora, se você deseja que o L2 tenha uma experiência de usuário de alto nível, você precisa ter sua própria pré-validação, o que significa um classificador centralizado ou seu próprio classificador descentralizado. Se o consenso se acelerar, o L2 não precisará mais fazer isso. Se você realmente deseja aumentar a escalabilidade do L1, a necessidade do L2 também será reduzida. Então, este é um espectro. No momento estou focando principalmente na versão dois da esquerda, mas as coisas que sugiro aqui também se aplicam a outras visões, e o conselho aqui não impede realmente outras visões. Isso é algo que considero muito importante. A vantagem de robustez do Ethereum
Uma grande vantagem do Ethereum é que ele possui um ecossistema de staking grande e relativamente descentralizado.

O lado esquerdo da imagem acima é o gráfico de taxa de hash de todos os pools de mineração de Bitcoin, e o lado direito é o gráfico de staker Ethereum. A distribuição do poder de computação do Bitcoin atualmente não é muito boa. Dois pools de mineração somam mais de 50% do poder de computação e quatro pools de mineração somam mais de 75%. E a situação do Ethereum é realmente melhor do que o gráfico mostra, porque a segunda grande parte da parte cinza não é realmente identificada, o que significa que pode ser uma combinação de muitas pessoas, e pode até haver muitos participantes independentes nela. A parte azul, Lido, é na verdade uma estrutura estranha e vagamente coordenada composta por 37 validadores diferentes. Portanto, o Ethereum, na verdade, tem um ecossistema de staking relativamente descentralizado que funciona muito bem. Podemos fazer muitas melhorias nesta área, mas penso que ainda há valor em reconhecer isto. Essa é uma das vantagens únicas que podemos realmente aproveitar.

As vantagens de robustez do Ethereum também incluem: ● Ter um ecossistema multicliente: existem clientes de execução Geth e clientes de execução não-Geth, e a proporção de clientes de execução não-Geth excede até mesmo a de clientes de execução Geth. Situação semelhante também ocorre no sistema de clientes de consenso; ● Comunidade internacional: as pessoas estão em muitos países diferentes, incluindo projetos, L2, equipes, etc.; ● Ecossistema de conhecimento multicêntrico: Existe a Fundação Ethereum e existem equipes de clientes; até mesmo equipes como a equipe Reth da Paradigm vêm aumentando recentemente sua liderança em código aberto, uma cultura que valoriza esses atributos. Portanto, o ecossistema Ethereum como camada base já possui essas vantagens muito poderosas. Acho que isso é algo muito valioso e não deve ser abandonado facilmente. Eu iria mais longe e diria que existem medidas claras que podem ser tomadas para promover estes pontos fortes e até mesmo resolver os nossos pontos fracos. Onde o Ethereum L1 não atende aos padrões elevados? Como pode ser melhorado?
Aqui está uma enquete que fiz no Farcaster há cerca de meio ano: Se você não está apostando Solo, o que o impede de apostar Solo? Posso repetir a pergunta neste local, quem está fazendo o staking Solo? Sem o staking Solo, qual de vocês sente que o limite de 32 ETH é o maior obstáculo, quem sente que executar um nó é muito difícil é o maior obstáculo, e quem sente que o maior obstáculo é não poder investir seu ETH em um Protocolo DeFi ao mesmo tempo? Quem sente que o maior obstáculo é o medo de ter que colocar chaves privadas em um nó em execução, onde possam ser roubadas com mais facilidade? Percebe-se que os dois principais obstáculos pactuados são: o requisito mínimo de 32 ETH e a dificuldade de operação do nó. É sempre importante perceber isso. Muitas vezes, quando começamos a investigar como maximizar a capacidade das pessoas de usarem suas garantias em protocolos DeFi, descobrimos que há um grande número de pessoas que nem mesmo usam protocolos DeFi. Portanto, vamos nos concentrar nas principais questões e no que podemos fazer para tentar resolvê-las. Comece executando um nó validador, ou seja, partindo do limite de 32 ETH. Na verdade, essas duas questões estão relacionadas porque ambas são funções do número de validadores na Prova de Participação do Ethereum. Hoje temos cerca de 1 milhão de entidades validadoras, cada uma com 32 ETH em depósito, então se o requisito mínimo fosse alterado para 4 ETH, então teríamos 8 milhões ou talvez mais de 8 milhões, talvez 9 milhões ou 10 milhões de validadores. Se quiséssemos chegar a 100.000 validadores, o requisito mínimo provavelmente subiria para cerca de 300 ETH. Então, é uma troca. Historicamente, Ethereum tem tentado estar no meio do trade-off. No entanto, se encontrarmos alguma maneira de melhorá-lo, teremos pontos de estatísticas extras que podemos usar opcionalmente para reduzir os requisitos mínimos ou para facilitar a execução do nó. Na verdade, agora acho que agregar assinaturas nem é a principal dificuldade de executar um nó. No início podemos concentrar-nos mais na redução dos requisitos mínimos, mas eventualmente isso envolverá ambos. Portanto, existem duas técnicas que podem melhorar esses dois aspectos. Uma técnica é permitir o staking ou permitir a finalidade sem exigir que cada validador assine.Basicamente, você precisa de algum tipo de amostragem aleatória de nós suficientes para alcançar uma segurança econômica significativa. Neste momento, penso que temos segurança económica mais do que suficiente. O custo de conduzir um ataque de 51%, em redução de ETH, é um terço de 32 milhões de ETH, o que equivale a cerca de 11 milhões de ETH. Quem gastaria 11 milhões de ETH para quebrar o blockchain Ethereum. Ninguém, nem mesmo o governo dos EUA, quer fazê-lo. Essas técnicas de amostragem são semelhantes às que você teria se tivesse uma casa e a porta da frente estivesse protegida por quatro camadas de aço, mas a janela fosse apenas um pedaço de vidro de baixa qualidade que alguém pudesse quebrar facilmente com um taco de beisebol. Acho que o Ethereum é assim até certo ponto, se você quiser fazer um ataque de 51%, terá que perder 11 milhões de ETH. Mas, na realidade, existem muitas outras formas de atacar o protocolo e deveríamos realmente reforçar mais estas defesas. Então, em vez disso, se você tiver um subconjunto de validadores fazendo finalidade, o protocolo ainda será seguro o suficiente e você poderá realmente aumentar o nível de descentralização. A segunda técnica é uma melhor agregação de assinaturas. Você poderia fazer algo avançado como Starks e, em vez de oferecer suporte a 30.000 assinaturas por slot, poderíamos eventualmente oferecer suporte a mais assinaturas. Esta é a primeira parte. A segunda parte é facilitar a execução dos nós. O primeiro passo é a expiração do histórico. Na verdade, EIP-4444, houve muito progresso nesse sentido. A segunda etapa é o cliente sem estado. Verkle já existe há muito tempo, outra opção possível é fazer uma árvore hash binária como Poseidon, uma função hash amigável do Stark. Depois de fazer isso, para verificar os blocos Ethereum, você não precisa mais de um disco rígido. Posteriormente, você também pode adicionar um ZKVM Tipo 1 que pode Stark verificar blocos Ethereum inteiros, para que você possa verificar blocos Ethereum arbitrariamente grandes baixando dados, ou mesmo dados de amostragem de disponibilidade de dados, e então você só precisa verificar uma prova. Se você fizer isso, a execução do nó ficará mais fácil. Uma das coisas muito irritantes atualmente com clientes sem estado é que se você quiser alterar as configurações de hardware ou software, normalmente você precisa começar do zero e perder um dia, ou precisa fazer algo muito perigoso e colocar as chaves em dois. será cortado em algum lugar, se tivermos um cliente sem estado, você não precisará mais fazer isso. Você pode simplesmente iniciar um novo cliente independente, fechar o antigo, mover as chaves e iniciar o novo. Você só perde uma época. Depois de ter o ZKVM, os requisitos de hardware basicamente caem para quase zero. Portanto, ambos os problemas, o limite de 32 ETH e a dificuldade de execução dos nós, podem ser resolvidos tecnicamente. Penso que há muitos outros benefícios em fazer isto, irá realmente melhorar a nossa capacidade de aumentar a aposta individual das pessoas, dar-nos-á um melhor ecossistema de aposta individual e evitará os riscos da centralização da aposta. A Prova de Participação tem outros desafios, como riscos relacionados ao staking líquido e riscos relacionados ao MEV. Estas também são questões importantes a serem consideradas. Nossos pesquisadores estão pensando sobre isso. Recuperar-se do ataque de 51%
Eu realmente comecei a pensar com seriedade e rigor. É surpreendente quantas pessoas nem pensam sobre esse assunto e apenas o tratam como uma caixa preta. O que acontece se realmente encontrarmos um ataque de 51%? Ethereum pode enfrentar um ataque de 51%, Bitcoin pode enfrentar um ataque de 51% e um governo também pode enfrentar um ataque de 51%, como comprar 51% de políticos. Um problema é que você não quer depender apenas da prevenção, você também quer ter um plano de recuperação. Um equívoco comum é que as pessoas pensam que 51% dos ataques têm como objetivo reverter a finalidade. As pessoas prestam atenção nisso porque é isso que Satoshi Nakamoto enfatizou no white paper. Você pode gastar o dobro, depois que comprei um jato particular, fiz um ataque de 51%, recuperei meus bitcoins e também mantive meu jato particular e voei por aí. Um ataque mais realista pode envolver a realização de depósitos em bolsas e coisas como comprometer protocolos DeFi. Mas a reversão não é realmente a pior coisa. O maior risco com o qual devemos nos preocupar é, na verdade, a censura. 51% dos nós pararam de aceitar blocos dos outros 49% dos nós ou de qualquer nó que tentasse conter algum tipo de transação. Por que este é o maior risco? Como a reversão de finalidade tem Slash, há provas verificáveis ​​imediatas na cadeia de que pelo menos um terço dos nós fizeram algo muito, muito errado e foram punidos. E num ataque de censura, não é atribuível processualmente, não há nenhuma evidência processual imediata que diga quem fez algo ruim. Agora, se você é um nó online, se quiser ver que uma determinada transação não foi incluída dentro de 100 blocos, mas, nem temos um software escrito para fazer essa verificação, outro desafio da revisão é se alguém quiser aos ataques, eles podem fazer isso, eles começam atrasando transações e bloqueios que não gostam por 30 segundos, depois atrasando por um minuto, depois atrasando por dois minutos, e você nem tem consenso sobre quando responder . Então, eu digo, a censura é na verdade o risco maior. Há um argumento na cultura blockchain de que, se houver um ataque, a comunidade se unirá e obviamente fará alguns soft forks e eliminará os invasores. Isto pode ser verdade hoje, mas depende de muitas suposições sobre coordenação, ideologia e todo o tipo de outras coisas, e não está claro até que ponto algo assim será verdadeiro daqui a 10 anos. Então, o que muitas outras comunidades de blockchain estão começando a fazer é, dizem, que temos coisas como censura, temos esses erros que são de natureza mais não atribuível. Portanto, devemos confiar no consenso social. Portanto, confiemos apenas no consenso social e tenhamos orgulho de admitir que o utilizaremos para resolver os nossos problemas. Na verdade, defendo ir na direção oposta. Sabemos que coordenar totalmente as respostas automatizadas e bifurcar automaticamente a maioria dos invasores sob análise é matematicamente impossível. Mas podemos chegar o mais próximo possível disso. Você pode criar uma bifurcação que realmente coloque pelo menos a maioria dos nós online com base em algumas suposições sobre as condições da rede. O argumento que estou tentando apresentar aqui é que o que realmente queremos é tentar tornar a resposta a um ataque de 51% o mais automatizada possível. Se você for um validador, então seu nó deve estar executando um software que, se detectar transações sendo censuradas ou certos validadores sendo censurados, ele irá automaticamente descensurar a maior parte da cadeia e todos os nós honestos irão automaticamente devido ao seu O código em execução é coordenado em os mesmos garfos macios. Claro, novamente há um resultado matematicamente impossível, pelo menos qualquer pessoa que estivesse offline no momento não seria capaz de dizer quem estava certo e quem estava errado. Existem muitas limitações, mas quanto mais perto você chega desse objetivo, menos trabalho o consenso social precisa fazer. Se você imaginar o que um ataque de 51% realmente acontece. Não vai ser como se, de repente, em algum momento, Lido, Coinbase e Kraken publicassem uma postagem no blog às 5:46 basicamente dizendo: ei pessoal, estamos fazendo uma revisão agora. O que pode realmente acontecer é que você verá uma guerra nas redes sociais ao mesmo tempo e verá todos os tipos de outros ataques ao mesmo tempo. A propósito, se de fato acontecer um ataque de 51%, quero dizer, não devemos presumir que Lido, Coinbase e Kraken estarão no poder em 10 anos. O ecossistema Ethereum se tornará cada vez mais popular e precisará ser altamente adaptável a isso.Queremos que o fardo sobre a camada social seja tão leve quanto possível, o que significa que precisamos que a camada técnica pelo menos apresente um candidato claramente vencedor, e se quiserem sair de uma cadeia que está em revisão, devem unir-se em torno de um punhado de garfos macios superiores. Defendo que façamos mais pesquisas e façamos uma recomendação muito específica. Proposta: Aumentar o limite do Quorum para 75% ou 80%
Acho que o limite para Quorum (Nota: o mecanismo de Quorum é um algoritmo de votação comumente usado em sistemas distribuídos para garantir redundância de dados e eventual consistência) pode ser aumentado de dois terços hoje para 75% ou 80% aproximadamente. O argumento básico é que se uma cadeia maliciosa, como uma cadeia de censura, atacar, a recuperação se tornará muito, muito difícil. Porém, por outro lado, se você aumentar a proporção do Quorum, quais são os riscos? Se o Quorum for 80%, então, em vez de 34% dos nós ficarem off-line, parando a finalidade, seriam 21% dos nós ficando off-line, parando a finalidade. Isso é arriscado. Vamos ver como fica na prática? Pelo que entendi, acho que apenas uma vez tivemos a finalidade paralisada por cerca de uma hora porque mais de um terço dos nós estavam offline. E então, houve algum incidente em que 20% a 33% dos nós estavam offline? Acho que uma vez no máximo e zero vezes pelo menos. Como na prática poucos validadores ficam offline, na verdade acho que o risco de fazer isso é muito baixo. Os benefícios são basicamente que o limite que um invasor precisa alcançar aumenta bastante e a gama de cenários em que a cadeia entra em modo de segurança no caso de uma vulnerabilidade do lado do cliente aumenta bastante, para que as pessoas possam realmente trabalhar juntas para descobrir o que deu errado. Se o limite do Quorum aumentar de 67% para 80%, então assumindo que a proporção que um cliente precisa atingir aumenta de 67% para 80%, então o valor de um pequeno número de clientes, ou o valor que um pequeno número de os clientes podem fornecer, realmente começa a aumentar. Outras preocupações de censura Outras preocupações de censura são as listas de inclusão ou alguma alternativa às listas de inclusão. Então, toda essa coisa de proponente multiparalelo, se funcionar, pode até se tornar um substituto para listas de inclusão. Você precisa de abstração de conta, precisa de abstração de conta dentro de algum tipo de protocolo. A razão pela qual você precisa disso é porque, no momento, as carteiras de contratos inteligentes não se beneficiam realmente das listas de inclusão. As carteiras de contratos inteligentes não se beneficiam realmente de qualquer tipo de garantia de resistência à censura na camada de protocolo. Eles se beneficiariam se houvesse abstração de contas dentro do protocolo. Então, há muitas coisas, na verdade muitas dessas coisas são valiosas na visão do centro L2 e na visão do centro L1. Das várias ideias que discuti, cerca de metade são provavelmente especificamente para soluções L2 para Ethereum, mas a outra metade é basicamente aplicável a usuários Ethereum com L2 como camada base e L1, ou aplicativos diretos ao usuário. Use clientes leves em qualquer lugar Em muitos aspectos, a forma como interagimos com a indústria é um pouco triste, somos descentralizados, não confiamos, quem nesta sala está executando um cliente leve em seu computador que valida o consenso? cru. Quem usa Ethereum confiando na carteira do navegador da Infura? Em cinco anos, gostaria de ver invertido o número de mãos levantadas. Gostaria de ver carteiras que não confiam na Infura para nada. Precisamos integrar clientes leves. A Infura pode continuar fornecendo dados. Quero dizer, é realmente bom para a Infura se você não precisar confiar na Infura, porque isso torna mais fácil para eles construir e implantar infraestrutura, mas temos ferramentas para remover o requisito de confiança. O que podemos fazer é ter um sistema onde o usuário final execute algo como um cliente Helios light. Na verdade, ele deve ser executado diretamente no navegador, validando diretamente o consenso Ethereum. Se ele quiser verificar algo na cadeia, como interagir com a cadeia, basta verificar a prova Merkle diretamente. Se você fizer isso, você realmente ganhará um certo grau de falta de confiança em suas interações com o Ethereum. Isto é para L1. Além disso, precisamos de um esquema equivalente para L2. Na cadeia L1, existem cabeçalhos de bloco, estados, comitês de sincronização e consenso. Se você verificar o consenso, se souber qual é o cabeçalho do bloco, poderá percorrer o branch Merkle e ver qual é o estado. Então, como podemos fornecer garantias leves de segurança do cliente para L2s. A raiz do estado de L2 está lá. Se for baseado em Rollup, existe um contrato inteligente e esse contrato inteligente armazena o cabeçalho do bloco de L2. Ou, se você tiver pré-confirmação, então você tem um contrato inteligente que armazena quem é a pré-confirmação, então você determina quem é a pré-confirmação e então ouve um subconjunto de dois terços de suas assinaturas. Assim, uma vez que você tenha o cabeçalho do bloco Ethereum, você terá uma cadeia de confiança bastante simples, o hash, a ramificação Merkle e a assinatura, que você pode verificar e obter uma verificação leve do cliente. O mesmo vale para qualquer L2. Já mencionei isso para pessoas no passado, e muitas vezes a resposta é: Oh meu Deus, isso é interessante, mas qual é o sentido?Muito L2 tem múltiplas assinaturas. Por que não confiamos em assinaturas múltiplas para verificar assinaturas múltiplas? Felizmente, desde o ano passado, isso não é mais verdade. Otimismo e Arbitrum estão na primeira fase do Rollup, o que significa que eles realmente têm sistemas de prova em execução na cadeia e um comitê de segurança que pode cobri-los em caso de vulnerabilidade, mas o comitê de segurança precisa passar por um limite de votação muito alto. , digamos 75% de 8 pessoas, o tamanho do Arbitrum aumentará para 15 pessoas. Portanto, no caso do Optimism e do Arbitrum, eles não são apenas multisigs, eles têm sistemas de prova reais, e esses sistemas de prova realmente têm um papel, pelo menos em termos de ter a maioria do poder para decidir qual cadeia está correta ou errada. . A EVM vai ainda mais longe, acredito que não tem nem comitê de segurança, então é totalmente confiável. Estamos realmente começando a avançar nisso, e sei que muitos outros L2s também estão avançando. Portanto, L2 é mais do que apenas multisig, então o conceito de clientes leves para L2 realmente começa a fazer sentido. Hoje já podemos verificar o branch Merkle, basta escrever o código. Amanhã também poderemos validar o ZKVM, para que você possa validar totalmente o Ethereum e o L2 na carteira do seu navegador. Quem quer ser um usuário Ethereum confiável em uma carteira de navegador? maravilhoso. Quem prefere ser um usuário confiável do Ethereum em seu celular? Que tal de um Raspberry Pi? E de um relógio inteligente? Da estação espacial? Nós vamos consertar isso também. Portanto, o que precisamos é do equivalente a uma configuração RPC que contenha não apenas os servidores com os quais você está se comunicando, mas também as instruções reais de autenticação do cliente leve. Isso é algo em que podemos trabalhar. Estratégia anti-quântica
O tempo para a computação quântica está diminuindo. Metaculous acredita que os computadores quânticos chegarão no início da década de 2030, e alguns pensam antes. Portanto, precisamos de uma estratégia resistente ao quantum. Temos uma estratégia resistente a quantum. Existem quatro partes do Ethereum que são vulneráveis ​​à computação quântica e cada uma tem alternativas naturais. A alternativa resistente quântica para Verkle Tree é Starked Poseidon Hash, ou se quisermos ser mais conservadores, podemos usar a assinatura de consenso de Blake, atualmente usamos assinatura agregada BLS, que pode ser substituída pela assinatura agregada Stark. Blob usa KZG, o que pode ser comprovado usando uma árvore Merkle Stark com codificação de separação. As contas de usuário atualmente usam ECDSA SECP256K1, que pode ser substituído por assinaturas baseadas em hash e abstração e agregação de contas, carteiras de contratos inteligentes ERC 4337, etc. Depois de fazer isso, o usuário pode configurar seu próprio algoritmo de assinatura, basicamente usando uma assinatura baseada em hash. Acho que realmente precisamos começar a pensar em construir assinaturas baseadas em hash para que as carteiras dos usuários possam facilmente atualizar para assinaturas baseadas em hash. Simplificação do protocolo Se você deseja uma camada base robusta, o protocolo precisa ser simples. Ele não deveria ter 73 ganchos aleatórios e alguma compatibilidade com versões anteriores que existe por causa de uma ideia aleatória e estúpida que um cara aleatório chamado Vitalik teve em 2014. Portanto, vale a pena tentar realmente simplificar e começar a eliminar realmente a dívida técnica. Atualmente, os logs são baseados em filtros bloom, que não funcionam bem e não são rápidos o suficiente, portanto, são necessárias melhorias nos logs para adicionar uma imutabilidade mais forte, o que já fazemos no lado sem estado, basicamente limitando o estado de cada visualização de bloco. Ethereum é uma coleção incrível no momento, existe RLP, existe SSZ, existe API e, idealmente, deveríamos apenas usar SSZ, mas pelo menos nos livrarmos do RLP, do estado e da árvore Merkle binária, uma vez que você tenha a árvore Merkle binária, então todo o Ethereum está em uma árvore Merkle binária. Fast Finality, Single Slot Finality (SSF), limpa pré-compiladores não utilizados, como o pré-compilador ModX, que muitas vezes causa erros de consenso, seria bom se pudéssemos removê-lo e substituí-lo por código de solidez de alto desempenho. Resumir Como uma camada base robusta, o Ethereum tem vantagens únicas, incluindo algumas que o Bitcoin não possui, como descentralização de consenso e pesquisas significativas sobre recuperação de ataques de 51%. Acho que há uma necessidade de realmente fortalecer esses pontos fortes. Reconhecer e corrigir também as nossas deficiências para garantir que cumprimos padrões muito elevados. Essas ideias são totalmente compatíveis com um roteiro L1 agressivo. Uma das coisas que mais me agrada no Ethereum, especialmente no processo central de desenvolvimento, é que nossa capacidade de trabalhar em paralelo melhorou significativamente. Esse é um ponto forte, podemos realmente trabalhar em muitas coisas em paralelo. Portanto, preocupar-se com esses tópicos não afeta de fato a capacidade de melhorar o ecossistema L1 e L2. Por exemplo, melhorando o EVM L1 para facilitar a criptografia. Atualmente, validar hashes Poseidon no EVM é muito caro. A criptografia de 384 bits também é muito cara. Portanto, existem algumas ideias além do EOF, como opcodes SIMD, EVM max, etc. Existe a oportunidade de anexar este coprocessador de alto desempenho ao EVM. Isso é melhor para a Camada 2 porque pode ser mais barato para verificar provas, e melhor para aplicativos da Camada 1 porque protocolos de privacidade como zk SNARKs são mais baratos. Quem usou o acordo de privacidade? Quem quer pagar uma taxa de US$ 40 em vez de US$ 80? Mais pessoas escolherão o primeiro. Um segundo grupo de usuários pode realizar transações na Camada 2, enquanto a Camada 1 pode reduzir significativamente os custos. ​