Ethereum "alterar RISC-V" assusta desenvolvedores? OG alerta: o ecossistema ETH será redistribuído, pequenos projetos podem sair para Solana.

O fundador do Ethereum, V God, propôs substituir "RISC-V" pelo Ethereum na camada de execução para substituir o EVM passado, o que fez com que alguns desenvolvedores desconfiassem, e em 2016, o desenvolvedor do Ethereum OG acreditava que isso faria com que o ecossistema Ethereum enfrentasse a redistribuição e fosse muito hostil a pequenos projetos de capital. (Sinopse: As taxas de manuseio do Ethereum atingiram uma mínima de cinco anos, e a comunidade desencadeou a "teoria do veneno L2": não há carros na estrada, e V Deus ainda está rindo e construindo rodovias) (Suplemento de fundo: Desmantelando a ambição estratégica de Vitalik de reconstruir a camada executiva do Ethereum com "RISC-V em vez de EVM" ) A recente proposta "RISC-V" do fundador do Ethereum V God atraiu a atenção da comunidade cripto e causou debate entre os principais desenvolvedores do ecossistema e, para a maioria dos usuários, a maioria deles não consegue entender o RISC-V Como reformar o Ethereum e que tipo de progresso a proposta de V-God pode trazer para o Ethereum? A fim de responder a esta pergunta, entrevistamos um antigo OG "dragão anti-escala" que vem desenvolvendo a ecologia central do Ethereum desde 2016, e ele responderá ao processo detalhado de revisão "RISC-V" e os efeitos negativos de curto prazo que podem ocorrer no futuro, lembrando a todos os investidores Ethereum para prestar muita atenção ao acompanhamento desta proposta. Como renovar a situação do RISC-V O Ethereum é diferente de outras cadeias PoS na medida em que o cliente Ethereum é composto por duas partes, a "camada de consenso" e a "camada de execução", e a camada de consenso é responsável pela votação de stake de empacotamento, e a camada de execução é responsável pelo processamento de transações, então o código que executa o contrato inteligente é, na verdade, um cliente de camada de execução executado pelo computador do nó, que executa o código pegando a transmissão da transação e escreve os resultados da votação através da "camada de consenso" no livro-razão público. A única maneira de atualizar o ambiente EVM atual para RISC-V é atualizando o "cliente da camada de execução" do cliente do nó, que é apenas uma bifurcação no nível de software, ao contrário do hard fork usual no passado para alterar o bloco Ethereum e a revisão do nó correspondente. De acordo com a descrição de conteúdo do artigo de V God, idealmente, se todos os clientes de nó tiverem executores RISC-V, então a operação do protocolo para a nova versão e a operação da prova zk pode atingir quase 100 vezes a eficiência teórica, mas deve-se saber que isso é calculado no contrato inteligente para a versão RISC-V e o cliente RISC-V, em relação ao formato de contrato inteligente EVM executado no cliente EVM. O que é especial sobre a proposta do RISC-V desta vez é que ele é diretamente renovado no cliente de camada executiva e não usará a parte de hard fork, que eu não gosto muito, mas pode ser visto que o Ethereum está se movendo em uma nova direção, que pode ser uma borda de dois gumes, e esse nível de mudança no passado Ethereum pode optar por ser implementado com um hard fork, porque pode ser uma abordagem mais segura. Correspondência entre a situação atual e o contrato antigo Depois de entender o desempenho da teoria, vamos ver qual é a situação atual, a situação atual é que toda a ecologia do Ethereum e todas as práticas de EIP são executadas com sucesso através de contratos inteligentes EVM e clientes EVM, se como V God disse que RISC-V terá um transpilador EVM, então a situação futura real pode ser dividida nas seguintes situações Os contratos inteligentes EVM são executados no cliente EVM (o EIP antigo é totalmente compatível, mas o novo EIP precisa corresponder a duas versões) O contrato inteligente EVM é executado no cliente RISC-V através do transpiler EVM do RISC-V (os EIPs antigos e novos precisam passar por muitos testes e depuração para resolver) O contrato inteligente RISC-V é executado no cliente RISC-V (o EIP antigo será todo testado, mas o novo EIP deve ser perfeitamente compatível) Em resumo, considerando o desempenho teórico da eficiência de operação do futuro contrato inteligente de 100 vezes, apenas o terceiro estado é aplicável, e para o segundo caso, Em particular, ele depende da otimização do transpiler pela equipe principal do Ethereum, bem como de todas as atualizações EIP e contratos inteligentes no passado, o que significa que o Ethereum precisa pagar um preço de otimização muito grande para alcançar uma melhoria teórica de desempenho, e é incerto se a otimização de eficiência do código EVM antigo através da tradução no RISC-V é definitivamente maior do que a do ambiente EVM nativo. Na verdade, V God disse isso, acho que deve haver muitos desenvolvedores principais se sentirem muito desesperados, no passado no desenvolvimento do EVM, para resolver cada implementação e teste EIP, a carga de trabalho já é muito grande, porque o Ethereum é uma comunidade que gosta de testar respostas abertas em um ambiente muito aberto. Mas agora quando ele se torna um ambiente RISC-V, eu só penso no período de teste de transformação, que é uma dor de cabeça muito, o problema central é que você pode não ser capaz de executar mais de 1 ~ 5 vezes mais eficiente do que o ambiente original durante o período de teste, então eu acho que esse período de teste continuará a ser estendido muitas vezes, assim como o Ethereum Merge no passado, de modo que há uma falta de resultados concretos no estágio inicial, e é difícil atrair ecossistemas externos para implantar na testnet e enviar feedback. Eu só posso dizer que V God tem grandes ambições, mas eu não acho que a implementação é muito otimista, pelo menos eu acho que mais da metade dos desenvolvedores principais podem não estar muito felizes, se eles estão determinados a mudar para RISC-V, V God e a Fundação Ethereum precisam gastar muito esforço para incentivar a equipe de desenvolvedores principais e ecologia. O problema da correspondência ecológica com RISC-V O dragão mencionou que o maior problema da proposta RISC-V pode vir do apoio e correspondência da ecologia do projeto privado, no ecossistema de código aberto existente, os componentes que podem ser usados são muito limitados, então o slogan de EVM para tradução RISC-V proposto por V Deus pode ter muitas dúvidas e problemas a curto prazo. Por exemplo, o ecossistema existente do Ethereum, como projetos EVM e contratos que não têm problemas, sob a premissa de EVM para tradução RISC-V, pode haver falta de estado ou término de operações no processo de execução do contrato na camada de execução, o que significa que mesmo projetos EVM antigos que não tiveram problemas no passado, no caso de usar EVM para tradução RISC-V, pode haver tokens que não podem ser propostos, ou acidentalmente queimados ou bloqueados. É muito provável que tal exemplo faça com que a equipe do projeto ecológico, em alguns casos, não esteja disposta a abrir os usuários para usar o transpiler EVM para RISC-V para executar contratos inteligentes EVM legados; Além disso, a fim de evitar riscos relacionados e acompanhar a nova tecnologia do Ethereum, a melhor maneira para o ecossistema do projeto é escrever uma nova versão RISC-V do contrato para todos os contratos inteligentes, e a conexão entre o contrato antigo e o novo contrato é resolvida por meio de ponte de ativos. Na verdade, a maneira de se envolver na compatibilidade é muito fácil de empacotar, mas se a fundação estiver disposta a espalhar dinheiro para obter a solução geral, então pode resolver 99% dos problemas de compatibilidade, mas o problema está no 1% restante e na confiança de segurança dos desenvolvedores ecológicos. Agora você pergunta aos desenvolvedores de projetos do Ethereum, eu acho que eu não vou estar tão confiante na parte da tradução EVM RISC-V, as empresas de tecnologia de grande capital querem pertencer aos seus próprios sistemas personalizados ou chips do início ao fim, eles não vão necessariamente escolher RISC-V, porque embora esta arquitetura seja de código aberto, em comparação com arquiteturas mainstream como ARM e X86, o suporte ecológico RISC-V é muito limitado, e não há desenvolvimento relacionado do blockchain, o que significa que o Ethereum tem que abrir um mundo com as próprias mãos. Se no exame...