No dia 8 de abril de 2025, o fundador do Ethereum, Vitalik, fará uma apresentação temática na Cimeira dos Académicos Web3 2025. A Golden Finance organizou o conteúdo da apresentação da seguinte forma.
Atualmente, a saída do Optimism ou Arbitrum requer um período de espera de 1 semana, o que causa muitos problemas.
Por que devemos nos importar com isso? Por que devemos nos importar com uma conexão mais rápida entre L2 e L1? Eu acho que há duas razões para mim. Uma delas é a experiência do usuário, queremos que os usuários tenham uma experiência melhor, esperar 1 semana é uma experiência ruim. A outra razão é que precisamos de um ecossistema mais integrado. Precisamos fazer algumas coisas para realmente melhorar o Optimism, Arbitrum, Polygon.
Estas partes do mundo Ethereum não são independentes.
Atualmente, a interoperabilidade entre L1 e L2 é muito rápida, mas requer muito Gas. Começamos a nos preocupar com esse problema desde o verão passado. As duas coisas que estamos focando incluem: endereços específicos da blockchain e projetos de intenção. Eu espero que transferir o Optimism para o Arbitrum não leve uma semana, e até mesmo espero que seja possível colocar o Optimism em um contrato inteligente.
Em um contrato inteligente, se alguém fornecer primeiro a prova de que enviou moeda para qualquer endereço de destino através do contrato, ele automaticamente saltará para esta etapa. Portanto, queremos encontrar a maneira adequada de reduzir o tempo de espera de uma semana o máximo possível.
Por que temos agora uma janela de retirada de uma semana? Porque o Rollup da Optimism precisa esperar uma semana para ver se alguém questiona seu hash; se ninguém questionar, você pode aceitar o hash. A vantagem da Optimism é que a tecnologia em que se baseia é muito cautelosa, mas o preço a pagar é esperar uma semana.
Se não quisermos esperar uma semana, precisamos estabelecer um sistema que possa empacotar blocos usando completamente um sistema de prova não otimista, como a combinação de ZK+TEE+OP - esta é a proposta de design que apresentamos.
Em condições normais, uma vez realizada uma transação L2, o estado será finalizado em L1 dentro de uma hora, reduzindo 1 hora para 12 segundos, o que é basicamente uma questão de eficiência. Portanto, esse é o primeiro objetivo. O segundo objetivo é que desejamos que o L2 seja sem confiança. Esperamos que o sistema possa determinar o estado correto e registrar estados errôneos, mesmo que os componentes que requerem confiança sejam comprometidos. Portanto, hoje, os Rollups estão em zero estágio ou no primeiro estágio, o que significa que eles colocam um certo grau de confiança ou total confiança em algum tipo de comitê de segurança. Você deve acreditar que o fabricante pode projetá-los corretamente. Você deve acreditar que o fabricante não manterá uma cópia da chave do site.
Além disso, você deve acreditar que o mecanismo de hardware não é algo que qualquer pessoa que possua hardware possa destruir, você deve acreditar que eles não conseguem encontrar uma maneira, como laser ou escaneamento infravermelho de hardware, de extrair informações sem danificar a visualização.
Agora, não queremos colocar toda a nossa confiança no ZK.
Você vai alocar confiança entre três mecanismos diferentes, que operam de acordo com tipos de lógica muito diferentes. Se tivermos esse design, então você pode reduzir o tempo de confirmação de 1 semana para 1 hora. A propósito, uma outra maneira é a minha visão anterior sobre sistemas de grupos, que eu basicamente dividi em duas categorias. Uma categoria é a confiança institucional, e a outra é a confiança criptográfica.
Outra dimensão é a rapidez e a lentidão. As coisas rápidas podem ser aprovadas imediatamente, enquanto as lentas precisam esperar um certo tempo. Curiosamente, assim como as quatro coisas aqui, elas são basicamente quatro componentes de sistemas de prova que as pessoas usam ou pensam no contexto de L2, certo? Se realmente pudéssemos colocá-las em uma caixa, elas se encaixariam perfeitamente em 2×2.
Primeiro passo, basicamente, reduzimos a janela de caminhada do diabo de 1 semana para 1 hora. O que isso lhe traz? Basicamente significa que, se você usar a ponte nativa para transferir ativos diretamente, seu tempo de espera será reduzido de 1 semana para 1 hora. Se você usar a ponte baseada em intenção, então a ponte baseada em intenção é instantânea, mas os provedores de liquidez não precisam esperar 1 hora, mas sim devem esperar 1 hora. O custo de fornecer liquidez foi reduzido em 168 vezes. Portanto, as taxas que você terá que pagar serão reduzidas em até 168 vezes.
L2s podem usar lowlookahead para leitura assíncrona de L1. Esta é uma funcionalidade que o L2 já possui, pois eles devem ser capazes de processar depósitos. Adotamos o mesmo estado que a leitura de depósitos e o expomos ao opcode L1SLOAD. Apoiar a leitura de dados de oráculos L1, carteiras de chaves e muitos outros aplicativos é algo extremamente valioso, pois um dos desafios frequentes que os L2 enfrentam é a necessidade de pagar grandes quantias.
Portanto, obtive várias aplicações personalizadas e integrações específicas. Isto realmente pode reduzir custos, porque em muitos casos, a alternativa poderá ler diretamente uma cópia da aplicação que já existe numa aplicação, o que é aplicável ao tratamento de dados. É aplicável a certas coisas, mas não é adequado para questões que necessitam de escrita por parte de alguém.
As carteiras de armazenamento de chaves são outra ideia interessante, não é? A ideia da carteira de armazenamento de chaves é basicamente que, na segurança da rede normal, você deseja trocar uma chave, não quer que a chave tenha um ciclo de vida infinito. Neo é parte do objetivo de abstração de contas, e hoje vou discutir esse objetivo.
Mas eu já falei várias vezes, basicamente é criar uma conta com qualquer lógica, assim você pode fazer algumas coisas, como alterar o algoritmo de criptografia, mudar a chave, tornando-as muito resistentes, e fazer com que utilizem snarks adicionados como métodos de recuperação. Agora, um dos desafios é que, se você pode mudar a chave, então você tem cem resultados após as alterações. Portanto, você precisa alterar o registro da chave atual em 100 lugares.
Como você resolve esse problema? Nós resolvemos esse problema colocando o registro da chave atual em um contrato central. Então você tem uma cópia da carteira em cada L2, que pode ser lida a partir do L1. Isso torna muitas práticas de segurança securitizadas muito razoáveis e muito semelhantes mais viáveis e práticas no mundo L2.
Outro benefício é que isso torna os fluxos de trabalho que incluem L2 e L1 mais fáceis e naturais para os desenvolvedores. Não estamos apenas falando de teoria e de um monte de cadeias completamente independentes, estamos realmente falando sobre a teoria L1 continuando a ser o núcleo da experiência do usuário para aplicações e pessoas.
O terceiro passo é a prova de agregação. Mencionei anteriormente que, se adotarmos este método baseado em duas ou três abordagens, ou no futuro, se fizermos uma validação formal muito boa, e dependermos apenas do ZK, poderemos reduzir o tempo de submissão de 1 semana para 1 hora. Por que 1 hora? Por que não 12 segundos? Há duas razões, e podemos resolver essas duas razões. A primeira razão é o custo de submissão. Portanto, submeter provas ao L1 requer uma sobrecarga adicional, cerca de 500.000 gas, e o custo do AA é muito alto.
Agora, se você imaginar que a cada período é submetida uma prova, então em um ano há 2,5 milhões de períodos. Gastamos 27,5 milhões de dólares por ano apenas para manter um valor relativo, isso é loucura. Quem aqui estaria disposto a pagar 27 milhões de dólares por ano? Mas se você submeter uma vez por minuto, em vez de uma vez a cada 12 segundos, então o custo de 27 milhões de dólares por ano se transforma em 5,5 milhões de dólares. Depois, se você submeter uma vez por hora, isso cairá para menos de 100 mil dólares por ano. Isso é realmente controlável. Esta solução natural é a agregação de provas.
Se tivermos uma grande variedade de ferramentas, então essas ferramentas não precisam ser apresentadas separadamente para diferentes grupos, a prova em cadeia pode ser agrupada, os grupos podem submeter suas provas a uma agregação, e então a agregação pode submeter uma única snark para provar a existência de outras snarks. O custo para validar essa snark é apenas um custo único de 500.000 gas. O que acontece aqui é basicamente o que está nesta imagem? Certo? Basicamente, você tem um monte de provas, e essas provas também especificam qual contrato. Estamos dentro de um bloco. Então você tem uma prova de agregação. A prova de agregação é validada. A prova de agregação contém todas as informações resumidas em uma única entrada pública e, em seguida, a prova ocorre apenas uma vez. Então, este contrato fará uma chamada para cada resumo uma única vez, e a única coisa que a chamada faz é carregar para cada resumo. O custo de cada vez reduz de 500.000 gas para menos de 10.000 gas.
Agora há um quarto passo, que é reduzir a latência da prova. O cálculo da prova leva mais tempo e mais capacidade de computação do que realizar o cálculo. Por padrão, este cálculo não paralisa. Você deve expandi-lo, e deve realizar esse cálculo muito intensivo.
Portanto, o resultado é que, em estado de equilíbrio, gerar um bloco que leva 5 segundos ainda requer 500 segundos para ser provado, certo? Este é um problema. Então a questão é, como resolvemos esse problema? Existem duas ideias. Uma é que podemos usar hardware dedicado para melhorá-lo. Algumas empresas já estão fazendo isso. Se você obtiver um fator de aceleração de hardware de 100 vezes, então você pode provar em tempo real. A outra ideia é a prova de super paralisação. Portanto, do ponto de vista matemático, isso na verdade é muito simples. Basicamente, você vai decompor o cálculo em várias etapas. Depois, você gera paralelamente a prova de cada etapa em dispositivos diferentes.
Se isso ainda não for suficiente, a velocidade de melhoria do hardware dedicado será ainda mais rápida. Além disso, o custo de melhoria também será menor. Portanto, temos muitas opções.
Se você usar o Intensive Optimism e o Arbitrum, ambos têm slots muito mais rápidos, então você também pode concluir em 2 segundos. Portanto, será muito barato. Assim, se você usar o Intensive, será capaz de transferir praticamente uma quantidade ilimitada de Ethereum rapidamente e a baixo custo. Portanto, isso também significa que podemos estabelecer uma ligação mais estreita entre L1 e L2. Temos um mundo mais integrado, onde tudo se torna mais fácil e rápido para todos. Obrigado.
O conteúdo serve apenas de referência e não constitui uma solicitação ou oferta. Não é prestado qualquer aconselhamento em matéria de investimento, fiscal ou jurídica. Consulte a Declaração de exoneração de responsabilidade para obter mais informações sobre os riscos.
Vatilik: Por que acelerar a velocidade de confirmação do L2? Como acelerar?
Organização: Wuzhu, Jinse Caijing
No dia 8 de abril de 2025, o fundador do Ethereum, Vitalik, fará uma apresentação temática na Cimeira dos Académicos Web3 2025. A Golden Finance organizou o conteúdo da apresentação da seguinte forma.
Atualmente, a saída do Optimism ou Arbitrum requer um período de espera de 1 semana, o que causa muitos problemas.
Por que devemos nos importar com isso? Por que devemos nos importar com uma conexão mais rápida entre L2 e L1? Eu acho que há duas razões para mim. Uma delas é a experiência do usuário, queremos que os usuários tenham uma experiência melhor, esperar 1 semana é uma experiência ruim. A outra razão é que precisamos de um ecossistema mais integrado. Precisamos fazer algumas coisas para realmente melhorar o Optimism, Arbitrum, Polygon.
Estas partes do mundo Ethereum não são independentes.
Atualmente, a interoperabilidade entre L1 e L2 é muito rápida, mas requer muito Gas. Começamos a nos preocupar com esse problema desde o verão passado. As duas coisas que estamos focando incluem: endereços específicos da blockchain e projetos de intenção. Eu espero que transferir o Optimism para o Arbitrum não leve uma semana, e até mesmo espero que seja possível colocar o Optimism em um contrato inteligente.
Em um contrato inteligente, se alguém fornecer primeiro a prova de que enviou moeda para qualquer endereço de destino através do contrato, ele automaticamente saltará para esta etapa. Portanto, queremos encontrar a maneira adequada de reduzir o tempo de espera de uma semana o máximo possível.
Por que temos agora uma janela de retirada de uma semana? Porque o Rollup da Optimism precisa esperar uma semana para ver se alguém questiona seu hash; se ninguém questionar, você pode aceitar o hash. A vantagem da Optimism é que a tecnologia em que se baseia é muito cautelosa, mas o preço a pagar é esperar uma semana.
Se não quisermos esperar uma semana, precisamos estabelecer um sistema que possa empacotar blocos usando completamente um sistema de prova não otimista, como a combinação de ZK+TEE+OP - esta é a proposta de design que apresentamos.
Em condições normais, uma vez realizada uma transação L2, o estado será finalizado em L1 dentro de uma hora, reduzindo 1 hora para 12 segundos, o que é basicamente uma questão de eficiência. Portanto, esse é o primeiro objetivo. O segundo objetivo é que desejamos que o L2 seja sem confiança. Esperamos que o sistema possa determinar o estado correto e registrar estados errôneos, mesmo que os componentes que requerem confiança sejam comprometidos. Portanto, hoje, os Rollups estão em zero estágio ou no primeiro estágio, o que significa que eles colocam um certo grau de confiança ou total confiança em algum tipo de comitê de segurança. Você deve acreditar que o fabricante pode projetá-los corretamente. Você deve acreditar que o fabricante não manterá uma cópia da chave do site.
Além disso, você deve acreditar que o mecanismo de hardware não é algo que qualquer pessoa que possua hardware possa destruir, você deve acreditar que eles não conseguem encontrar uma maneira, como laser ou escaneamento infravermelho de hardware, de extrair informações sem danificar a visualização.
Agora, não queremos colocar toda a nossa confiança no ZK.
Você vai alocar confiança entre três mecanismos diferentes, que operam de acordo com tipos de lógica muito diferentes. Se tivermos esse design, então você pode reduzir o tempo de confirmação de 1 semana para 1 hora. A propósito, uma outra maneira é a minha visão anterior sobre sistemas de grupos, que eu basicamente dividi em duas categorias. Uma categoria é a confiança institucional, e a outra é a confiança criptográfica.
Outra dimensão é a rapidez e a lentidão. As coisas rápidas podem ser aprovadas imediatamente, enquanto as lentas precisam esperar um certo tempo. Curiosamente, assim como as quatro coisas aqui, elas são basicamente quatro componentes de sistemas de prova que as pessoas usam ou pensam no contexto de L2, certo? Se realmente pudéssemos colocá-las em uma caixa, elas se encaixariam perfeitamente em 2×2.
Primeiro passo, basicamente, reduzimos a janela de caminhada do diabo de 1 semana para 1 hora. O que isso lhe traz? Basicamente significa que, se você usar a ponte nativa para transferir ativos diretamente, seu tempo de espera será reduzido de 1 semana para 1 hora. Se você usar a ponte baseada em intenção, então a ponte baseada em intenção é instantânea, mas os provedores de liquidez não precisam esperar 1 hora, mas sim devem esperar 1 hora. O custo de fornecer liquidez foi reduzido em 168 vezes. Portanto, as taxas que você terá que pagar serão reduzidas em até 168 vezes.
L2s podem usar lowlookahead para leitura assíncrona de L1. Esta é uma funcionalidade que o L2 já possui, pois eles devem ser capazes de processar depósitos. Adotamos o mesmo estado que a leitura de depósitos e o expomos ao opcode L1SLOAD. Apoiar a leitura de dados de oráculos L1, carteiras de chaves e muitos outros aplicativos é algo extremamente valioso, pois um dos desafios frequentes que os L2 enfrentam é a necessidade de pagar grandes quantias.
Portanto, obtive várias aplicações personalizadas e integrações específicas. Isto realmente pode reduzir custos, porque em muitos casos, a alternativa poderá ler diretamente uma cópia da aplicação que já existe numa aplicação, o que é aplicável ao tratamento de dados. É aplicável a certas coisas, mas não é adequado para questões que necessitam de escrita por parte de alguém.
As carteiras de armazenamento de chaves são outra ideia interessante, não é? A ideia da carteira de armazenamento de chaves é basicamente que, na segurança da rede normal, você deseja trocar uma chave, não quer que a chave tenha um ciclo de vida infinito. Neo é parte do objetivo de abstração de contas, e hoje vou discutir esse objetivo.
Mas eu já falei várias vezes, basicamente é criar uma conta com qualquer lógica, assim você pode fazer algumas coisas, como alterar o algoritmo de criptografia, mudar a chave, tornando-as muito resistentes, e fazer com que utilizem snarks adicionados como métodos de recuperação. Agora, um dos desafios é que, se você pode mudar a chave, então você tem cem resultados após as alterações. Portanto, você precisa alterar o registro da chave atual em 100 lugares.
Como você resolve esse problema? Nós resolvemos esse problema colocando o registro da chave atual em um contrato central. Então você tem uma cópia da carteira em cada L2, que pode ser lida a partir do L1. Isso torna muitas práticas de segurança securitizadas muito razoáveis e muito semelhantes mais viáveis e práticas no mundo L2.
Outro benefício é que isso torna os fluxos de trabalho que incluem L2 e L1 mais fáceis e naturais para os desenvolvedores. Não estamos apenas falando de teoria e de um monte de cadeias completamente independentes, estamos realmente falando sobre a teoria L1 continuando a ser o núcleo da experiência do usuário para aplicações e pessoas.
O terceiro passo é a prova de agregação. Mencionei anteriormente que, se adotarmos este método baseado em duas ou três abordagens, ou no futuro, se fizermos uma validação formal muito boa, e dependermos apenas do ZK, poderemos reduzir o tempo de submissão de 1 semana para 1 hora. Por que 1 hora? Por que não 12 segundos? Há duas razões, e podemos resolver essas duas razões. A primeira razão é o custo de submissão. Portanto, submeter provas ao L1 requer uma sobrecarga adicional, cerca de 500.000 gas, e o custo do AA é muito alto.
Agora, se você imaginar que a cada período é submetida uma prova, então em um ano há 2,5 milhões de períodos. Gastamos 27,5 milhões de dólares por ano apenas para manter um valor relativo, isso é loucura. Quem aqui estaria disposto a pagar 27 milhões de dólares por ano? Mas se você submeter uma vez por minuto, em vez de uma vez a cada 12 segundos, então o custo de 27 milhões de dólares por ano se transforma em 5,5 milhões de dólares. Depois, se você submeter uma vez por hora, isso cairá para menos de 100 mil dólares por ano. Isso é realmente controlável. Esta solução natural é a agregação de provas.
Se tivermos uma grande variedade de ferramentas, então essas ferramentas não precisam ser apresentadas separadamente para diferentes grupos, a prova em cadeia pode ser agrupada, os grupos podem submeter suas provas a uma agregação, e então a agregação pode submeter uma única snark para provar a existência de outras snarks. O custo para validar essa snark é apenas um custo único de 500.000 gas. O que acontece aqui é basicamente o que está nesta imagem? Certo? Basicamente, você tem um monte de provas, e essas provas também especificam qual contrato. Estamos dentro de um bloco. Então você tem uma prova de agregação. A prova de agregação é validada. A prova de agregação contém todas as informações resumidas em uma única entrada pública e, em seguida, a prova ocorre apenas uma vez. Então, este contrato fará uma chamada para cada resumo uma única vez, e a única coisa que a chamada faz é carregar para cada resumo. O custo de cada vez reduz de 500.000 gas para menos de 10.000 gas.
Agora há um quarto passo, que é reduzir a latência da prova. O cálculo da prova leva mais tempo e mais capacidade de computação do que realizar o cálculo. Por padrão, este cálculo não paralisa. Você deve expandi-lo, e deve realizar esse cálculo muito intensivo.
Portanto, o resultado é que, em estado de equilíbrio, gerar um bloco que leva 5 segundos ainda requer 500 segundos para ser provado, certo? Este é um problema. Então a questão é, como resolvemos esse problema? Existem duas ideias. Uma é que podemos usar hardware dedicado para melhorá-lo. Algumas empresas já estão fazendo isso. Se você obtiver um fator de aceleração de hardware de 100 vezes, então você pode provar em tempo real. A outra ideia é a prova de super paralisação. Portanto, do ponto de vista matemático, isso na verdade é muito simples. Basicamente, você vai decompor o cálculo em várias etapas. Depois, você gera paralelamente a prova de cada etapa em dispositivos diferentes.
Se isso ainda não for suficiente, a velocidade de melhoria do hardware dedicado será ainda mais rápida. Além disso, o custo de melhoria também será menor. Portanto, temos muitas opções.
Se você usar o Intensive Optimism e o Arbitrum, ambos têm slots muito mais rápidos, então você também pode concluir em 2 segundos. Portanto, será muito barato. Assim, se você usar o Intensive, será capaz de transferir praticamente uma quantidade ilimitada de Ethereum rapidamente e a baixo custo. Portanto, isso também significa que podemos estabelecer uma ligação mais estreita entre L1 e L2. Temos um mundo mais integrado, onde tudo se torna mais fácil e rápido para todos. Obrigado.