Compilado por: 0xxz, Golden Finance
O EthCC7 foi realizado recentemente em Bruxelas, e os organizadores convidaram Vitalik, o fundador do Ethereum, para fazer um discurso de abertura.
É importante notar que 2024 marca o 10º aniversário do Ethereum ICO Após o discurso de Vitalik, os três principais fundadores do 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 recentemente por Vitalik, o fundador da Ethereum, na EthCC7.
o tema do discurso
Fortalecendo 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 verificador 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 nos dApps executados 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 camada base de L2 na segunda 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, opções muito extremas estão à esquerda e à direita pode ser uma camada base, mas também tentam 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 é realmente tornar viáveis os rollups básicos como a principal forma de operação do 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é-confirmaçã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, é 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.
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 é um gráfico do poder computacional de todos os pools de mineração de Bitcoin, e o lado direito é um gráfico dos stakers 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 stakers 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. Esse é um dos pontos fortes únicos que podemos realmente desenvolver.
As vantagens de robustez do Ethereum também incluem:
Possui um ecossistema multicliente: existem clientes de execução Geth e clientes de execução não Geth. A proporção de clientes de execução não Geth excede até mesmo a de clientes de execução Geth. Uma situação semelhante ocorre em sistemas clientes de consenso;
Comunidade internacional: pessoas em diversos países, incluindo projetos, L2, equipes, etc.;
Ecossistema de conhecimento multicêntrico: Existe a Fundação Ethereum, existe a equipe do cliente e até a equipe Reth da Paradigm vem aumentando sua liderança em código aberto recentemente;
Culturas que valorizam 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 a padrões elevados e 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 é que você não pode investir seu ETH no DeFi protocolo 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 acordados por unanimidade 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 um depósito de 32 ETH, 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 quisermos reduzi-lo para 100.000 validadores, então o requisito mínimo poderá ter que subir para cerca de 300 ETH.
Então, é uma troca. Historicamente, Ethereum tem tentado estar no meio do trade-off. No entanto, se pudermos encontrar alguma maneira de melhorá-lo, teremos pontos de estatísticas adicionais que poderemos usar opcionalmente para reduzir os requisitos mínimos ou para facilitar a execução de um 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 seria permitir o staking ou permitir a finalidade sem exigir que todos os validadores assinem. 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%, calculado em termos da quantidade de ETH cortada, é um terço de 32 milhões de ETH, o que equivale a aproximadamente 11 milhões de ETH. Quem gastaria 11 milhões de ETH para destruir o blockchain Ethereum. Ninguém, nem mesmo o governo dos EUA, quer fazê-lo.
Essas técnicas de amostragem são semelhantes a se você tivesse uma casa e a porta da frente fosse protegida por quatro camadas de aço, mas a janela fosse apenas um pedaço de vidro de baixa qualidade que alguém poderia 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 de nós.
O primeiro passo é a expiração do histórico. Na verdade, EIP-4444, houve muito progresso nesta área.
A segunda etapa é o cliente sem estado. Verkle já existe há muito tempo, outra opção possível é fazer uma árvore hash binária semelhante ao Poseidon com uma função hash amigável ao Stark. Depois de fazer isso, para verificar os blocos Ethereum, você não precisa mais de um disco rígido. Você pode então adicionar um ZKVM Tipo 1 que pode Stark verificar todo o bloco Ethereum, para que você possa verificar blocos Ethereum arbitrariamente grandes baixando dados ou até 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. seria um Slah, se tivermos clientes apátridas você não precisa 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, tanto o limite de 32 ETH quanto a dificuldade de operação do nó 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 à aposta de liquidez 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 acontecerá se realmente encontrarmos um ataque de 51%?
O Ethereum pode sofrer um ataque de 51%, o Bitcoin pode sofrer um ataque de 51% e um governo também pode sofrer um ataque de 51%, como comprar 51% dos 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 meu jato particular, fiz um ataque de 51%, recuperei meus bitcoins e consegui manter meu jato particular e voar por aí.
Um ataque mais realista pode envolver a realização de depósitos em bolsas e coisas como comprometer protocolos DeFi.
Mas uma 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á evidências 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 em 100 blocos, mas ainda não escrevemos um software para fazer essa verificação,
Outro desafio da censura é que se alguém quiser atacar, pode fazê-lo atrasando transações e bloqueios que não gosta por 30 segundos, depois atrasando por um minuto, depois atrasando por dois minutos, e você nem sequer chegar a um consenso sobre quando responder.
Então, eu digo, na verdade a censura é 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.
Isso pode ser verdade hoje, mas depende de muitas suposições sobre coordenação, ideologia e todo 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 blockchain estão começando a fazer é, dizem, temos coisas como censura, temos esses erros que são de natureza mais inatribuí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 transmitir 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 torna 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%, em vez de 34% dos nós ficarem offline parando a finalidade, serão 21% dos nós ficando offline parando a finalidade.
Existem riscos. 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, há algum incidente em que 20% a 33% dos nós estão 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 colaborar para descobrir o que foi 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 da lista 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.
Eu acho que, das diferentes ideias que falei, provavelmente cerca de metade eram especificamente para Ethereum focado em L2, mas a outra metade era basicamente, para L2 como uma camada base para usuários de Ethereum e L1, ou, tipo, diretamente para aplicativos de usuários como do utilizador.
Use clientes leves em qualquer lugar
De muitas maneiras, é meio triste como interagimos com o espaço, 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, se você não precisa confiar na Infura, isso é realmente bom para a Infura porque torna mais fácil para eles construir e implantar infraestrutura, mas temos ferramentas para remover a exigência 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, também precisamos de uma solução 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 um Rollup básico, 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, há uma cadeia bastante simples de confiança, hash, branch merkle e 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 no primeiro estágio 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. , como 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égias Resistentes Quânticas
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.
Uma alternativa resistente quântica para Verkle Tree é Starked Poseidon Hash, ou se quisermos ser mais conservadores, podemos usar assinaturas de consenso de Blake, atualmente usamos assinaturas agregadas BLS, que podem ser substituídas por assinaturas agregadas Stark. Blob usa KZG e pode ser comprovado usando codificação separada Merkle tree Stark. 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 obtê-los, o usuário pode configurar seu próprio algoritmo de assinatura, essencialmente 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 o agressivo roteiro L1.
Uma das coisas que mais me agrada no Ethereum e no processo central de desenvolvimento em particular é 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, na verdade, a capacidade de melhorar o ecossistema L1 e L2. Por exemplo, melhorando o EVM L1 para facilitar a criptografia. Atualmente é muito caro verificar hashes Poseidon no EVM. 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 eles podem verificar as provas de forma mais barata, 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 40 taxas em vez de 80 taxas com um acordo de privacidade? mais pessoas. O segundo grupo pode ser usado na Camada 2, e a Camada 1 pode obter economias de custos significativas.
Os “Três Grandes” do Ethereum se reúnem
2024 é o 10º aniversário do Ethereum IC0 O 2024 EthCC convidou todos os três ex-fundadores principais do Ethereum, Vitalik Buterin, Joseph Lubin e Gavin Wood, para participar da reunião.
Após a fala de Vitalik, eles foram convidados a tirar uma foto em grupo juntos:
Os Três Grandes apertam as mãos novamente
