Discussão sobre soluções práticas para aumentar a velocidade de confirmação de transações no Ethereum
Ethereum tem feito progressos significativos na velocidade de confirmação de transações nos últimos anos. Atualmente, as transações enviadas pelos usuários na L1 geralmente podem ser confirmadas em 5-20 segundos, o que é comparável à experiência de pagamento com cartão de crédito. No entanto, ainda é necessário melhorar a experiência do usuário, pois algumas aplicações exigem que a latência seja reduzida para algumas centenas de milissegundos. Este artigo explorará algumas opções viáveis para melhorar o tempo de confirmação de transações no Ethereum.
Visão Geral da Tecnologia e Abordagens Existentes
finalização de slot único
O mecanismo de consenso Gasper atualmente utilizado pelo Ethereum adota uma arquitetura de slot único e Epoch. Cada slot dura 12 segundos, e alguns validadores votam no cabeçalho da cadeia; dentro de 32 slots (6,4 minutos), todos os validadores têm a oportunidade de votar uma vez. Esses votos são então interpretados como mensagens semelhantes ao algoritmo de consenso PBFT, e após dois Epochs (12,8 minutos), fornece uma forte garantia econômica chamada de finalização.
No entanto, este método apresenta dois problemas principais: alta complexidade e um tempo de confirmação final de 12,8 minutos que é demasiado longo. Para resolver esses problemas, a Finalidade de Slot Único (Single Slot Finality, SSF) propôs um mecanismo semelhante ao consenso Tendermint, que completa a confirmação final do bloco atual antes de gerar o próximo bloco.
O principal desafio do SSF é que cada validador precisa publicar duas mensagens a cada 12 segundos, o que impõe um enorme fardo à rede. Embora haja algumas ideias inovadoras, como a proposta Orbit SSF, que tentam aliviar esse problema, os usuários ainda precisam esperar de 5 a 20 segundos para confirmar a transação.
Pré-confirmação de Rollup
Com a adoção do Ethereum de uma abordagem centrada em rollup, os protocolos L2 (como rollups, validiums e plasmas) conseguem oferecer serviços em larga escala com um nível de segurança equivalente ao do Ethereum. Isso resultou numa divisão de responsabilidades dentro do ecossistema Ethereum: L1 foca na resistência à censura, confiabilidade e na manutenção e melhoria das funções principais, enquanto L2 se dedica a atender diretamente às necessidades dos usuários através de diferentes tecnologias e culturas.
Em teoria, o L2 pode criar sua própria rede de "ordenadores descentralizados", onde um pequeno grupo de validadores assina blocos a cada poucas centenas de milissegundos, utilizando seus ativos em staking como garantia. Os cabeçalhos destes blocos L2 serão eventualmente publicados no L1.
No entanto, exigir que todos os L2 estabeleçam uma rede de ordenação descentralizada parece pouco realista, o que equivale a exigir que o rollup complete um trabalho quase idêntico ao de criar um novo L1. Assim, foi proposto que todos os L2 (e L1) compartilhem um mecanismo de pré-confirmação dentro do âmbito do Ethereum: pré-confirmação básica.
Confirmação prévia básica
O método de pré-confirmação básica assume que os proponentes do Ethereum são participantes altamente complexos. Este método utiliza a especialização desses proponentes ao incentivá-los a aceitar a responsabilidade de fornecer serviços de pré-confirmação.
A ideia central é criar um protocolo padronizado, onde os usuários podem pagar uma taxa adicional para obter a garantia imediata de que suas transações serão incluídas no próximo bloco, bem como uma declaração sobre o resultado da execução da transação. Se o proponente violar a promessa, enfrentará penalidades.
Este mecanismo não se aplica apenas às transações L1, mas também para rollups "baseados" em Ethereum, uma vez que todos os blocos L2 são essencialmente transações L1, portanto, o mesmo mecanismo também pode fornecer serviços de pré-confirmação para qualquer L2.
Direção futura de desenvolvimento
Suponha que implementemos a finalização em um único slot e usemos uma tecnologia semelhante ao Orbit para reduzir o número de validadores por slot, mantendo ao mesmo tempo um nível suficiente de descentralização para diminuir o limiar de staking. A duração do slot pode aumentar para 16 segundos, e então podemos utilizar pré-confirmação de rollup ou pré-confirmação básica para oferecer confirmações mais rápidas aos usuários. Assim, acabamos com uma arquitetura de epoch-slot.
Esta arquitetura é difícil de evitar principalmente porque o tempo necessário para alcançar um consenso geral sobre algo é muito menor do que o tempo necessário para alcançar a "finalidade econômica" máxima. As principais razões incluem:
"Consenso aproximado" requer a participação de poucos nós, enquanto a finalidade económica requer a participação da maioria dos nós.
Depois que o número de nós ultrapassa uma certa escala, o tempo necessário para coletar assinaturas aumenta significativamente.
Portanto, a arquitetura de epoch-and-slot parece ser a direção de desenvolvimento correta, mas diferentes maneiras de implementação podem ter efeitos diferentes. Vale a pena explorar mais a possibilidade de estabelecer uma separação de atenção mais forte entre os dois mecanismos, em vez de estar fortemente acoplada como o Gasper.
Estratégia de desenvolvimento do L2
Para L2, atualmente existem três estratégias de desenvolvimento razoáveis:
Em termos técnicos e de conceito, "baseado" no Ethereum, otimizando suas características e valores fundamentais.
Tornar-se um "servidor com andaimes de blockchain", aproveitando ao máximo a eficiência dos servidores centralizados, ao mesmo tempo que garante segurança e descentralização ao adicionar elementos de blockchain.
Solução de compromisso: estabelecer uma cadeia rápida com cerca de cem nós, ao mesmo tempo em que utiliza o Ethereum para fornecer interoperabilidade e segurança adicionais.
Para diferentes cenários de aplicação, essas três estratégias têm suas vantagens. Uma questão chave é até que ponto conseguimos otimizar na arquitetura nativa de epoch e slot do Ethereum. Se conseguirmos reduzir o tempo de slot para 1 segundo, o espaço da terceira estratégia pode diminuir significativamente.
Atualmente, ainda estamos a alguma distância das respostas finais para estas questões. A complexidade dos proponentes de blocos, o potencial de novos designs como o Orbit SSF e outros fatores apresentam uma grande incerteza. Continuar a explorar e a aperfeiçoar estas soluções ajudará a proporcionar uma melhor experiência para os utilizadores de L1 e L2, ao mesmo tempo que simplifica o trabalho dos desenvolvedores de L2.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
14 Curtidas
Recompensa
14
4
Repostar
Compartilhar
Comentário
0/400
NotAFinancialAdvice
· 1h atrás
o tps ainda precisa ser acelerado
Ver originalResponder0
BugBountyHunter
· 1h atrás
A velocidade de transação ainda não é rápida o suficiente.
Ver originalResponder0
AirdropF5Bro
· 1h atrás
Sem mercado, apenas F5 Airdrop.
Ver originalResponder0
pvt_key_collector
· 1h atrás
Para que serve a velocidade? Primeiro é preciso sobreviver.
Discussão sobre planos de aceleração do Ethereum: finalização única de slot, pré-confirmação de Rollup e pré-confirmação básica
Discussão sobre soluções práticas para aumentar a velocidade de confirmação de transações no Ethereum
Ethereum tem feito progressos significativos na velocidade de confirmação de transações nos últimos anos. Atualmente, as transações enviadas pelos usuários na L1 geralmente podem ser confirmadas em 5-20 segundos, o que é comparável à experiência de pagamento com cartão de crédito. No entanto, ainda é necessário melhorar a experiência do usuário, pois algumas aplicações exigem que a latência seja reduzida para algumas centenas de milissegundos. Este artigo explorará algumas opções viáveis para melhorar o tempo de confirmação de transações no Ethereum.
Visão Geral da Tecnologia e Abordagens Existentes
finalização de slot único
O mecanismo de consenso Gasper atualmente utilizado pelo Ethereum adota uma arquitetura de slot único e Epoch. Cada slot dura 12 segundos, e alguns validadores votam no cabeçalho da cadeia; dentro de 32 slots (6,4 minutos), todos os validadores têm a oportunidade de votar uma vez. Esses votos são então interpretados como mensagens semelhantes ao algoritmo de consenso PBFT, e após dois Epochs (12,8 minutos), fornece uma forte garantia econômica chamada de finalização.
No entanto, este método apresenta dois problemas principais: alta complexidade e um tempo de confirmação final de 12,8 minutos que é demasiado longo. Para resolver esses problemas, a Finalidade de Slot Único (Single Slot Finality, SSF) propôs um mecanismo semelhante ao consenso Tendermint, que completa a confirmação final do bloco atual antes de gerar o próximo bloco.
O principal desafio do SSF é que cada validador precisa publicar duas mensagens a cada 12 segundos, o que impõe um enorme fardo à rede. Embora haja algumas ideias inovadoras, como a proposta Orbit SSF, que tentam aliviar esse problema, os usuários ainda precisam esperar de 5 a 20 segundos para confirmar a transação.
Pré-confirmação de Rollup
Com a adoção do Ethereum de uma abordagem centrada em rollup, os protocolos L2 (como rollups, validiums e plasmas) conseguem oferecer serviços em larga escala com um nível de segurança equivalente ao do Ethereum. Isso resultou numa divisão de responsabilidades dentro do ecossistema Ethereum: L1 foca na resistência à censura, confiabilidade e na manutenção e melhoria das funções principais, enquanto L2 se dedica a atender diretamente às necessidades dos usuários através de diferentes tecnologias e culturas.
Em teoria, o L2 pode criar sua própria rede de "ordenadores descentralizados", onde um pequeno grupo de validadores assina blocos a cada poucas centenas de milissegundos, utilizando seus ativos em staking como garantia. Os cabeçalhos destes blocos L2 serão eventualmente publicados no L1.
No entanto, exigir que todos os L2 estabeleçam uma rede de ordenação descentralizada parece pouco realista, o que equivale a exigir que o rollup complete um trabalho quase idêntico ao de criar um novo L1. Assim, foi proposto que todos os L2 (e L1) compartilhem um mecanismo de pré-confirmação dentro do âmbito do Ethereum: pré-confirmação básica.
Confirmação prévia básica
O método de pré-confirmação básica assume que os proponentes do Ethereum são participantes altamente complexos. Este método utiliza a especialização desses proponentes ao incentivá-los a aceitar a responsabilidade de fornecer serviços de pré-confirmação.
A ideia central é criar um protocolo padronizado, onde os usuários podem pagar uma taxa adicional para obter a garantia imediata de que suas transações serão incluídas no próximo bloco, bem como uma declaração sobre o resultado da execução da transação. Se o proponente violar a promessa, enfrentará penalidades.
Este mecanismo não se aplica apenas às transações L1, mas também para rollups "baseados" em Ethereum, uma vez que todos os blocos L2 são essencialmente transações L1, portanto, o mesmo mecanismo também pode fornecer serviços de pré-confirmação para qualquer L2.
Direção futura de desenvolvimento
Suponha que implementemos a finalização em um único slot e usemos uma tecnologia semelhante ao Orbit para reduzir o número de validadores por slot, mantendo ao mesmo tempo um nível suficiente de descentralização para diminuir o limiar de staking. A duração do slot pode aumentar para 16 segundos, e então podemos utilizar pré-confirmação de rollup ou pré-confirmação básica para oferecer confirmações mais rápidas aos usuários. Assim, acabamos com uma arquitetura de epoch-slot.
Esta arquitetura é difícil de evitar principalmente porque o tempo necessário para alcançar um consenso geral sobre algo é muito menor do que o tempo necessário para alcançar a "finalidade econômica" máxima. As principais razões incluem:
Portanto, a arquitetura de epoch-and-slot parece ser a direção de desenvolvimento correta, mas diferentes maneiras de implementação podem ter efeitos diferentes. Vale a pena explorar mais a possibilidade de estabelecer uma separação de atenção mais forte entre os dois mecanismos, em vez de estar fortemente acoplada como o Gasper.
Estratégia de desenvolvimento do L2
Para L2, atualmente existem três estratégias de desenvolvimento razoáveis:
Para diferentes cenários de aplicação, essas três estratégias têm suas vantagens. Uma questão chave é até que ponto conseguimos otimizar na arquitetura nativa de epoch e slot do Ethereum. Se conseguirmos reduzir o tempo de slot para 1 segundo, o espaço da terceira estratégia pode diminuir significativamente.
Atualmente, ainda estamos a alguma distância das respostas finais para estas questões. A complexidade dos proponentes de blocos, o potencial de novos designs como o Orbit SSF e outros fatores apresentam uma grande incerteza. Continuar a explorar e a aperfeiçoar estas soluções ajudará a proporcionar uma melhor experiência para os utilizadores de L1 e L2, ao mesmo tempo que simplifica o trabalho dos desenvolvedores de L2.