Discussão sobre soluções para otimizar o tempo de confirmação de transações no Ethereum
Um aspecto importante da experiência do usuário em blockchain é o rápido tempo de confirmação de transações. Nos últimos anos, o Ethereum fez progressos significativos nessa área. Graças ao EIP-1559 e à estabilidade do tempo de bloco após a transição para PoS, as transações enviadas pelos usuários na L1 geralmente podem ser confirmadas em 5 a 20 segundos, o que é basicamente equivalente à experiência de pagamento com cartão de crédito. No entanto, ainda é valioso melhorar ainda mais a experiência do usuário, pois algumas aplicações exigem até mesmo latências sub-segundo. Este artigo explorará algumas opções viáveis para o Ethereum melhorar o tempo de confirmação de transações.
Visão Geral da Tecnologia Existente
finalização de slot único
Atualmente, o consenso Gasper do Ethereum adota uma arquitetura de slot único e Epoch. A cada 12 segundos um slot, alguns validadores votam no cabeçalho da cadeia, e todos os validadores têm a oportunidade de votar uma vez em 32 slots. Esses votos são reinterpretados como mensagens semelhantes ao algoritmo de consenso PBFT, fornecendo uma finalização com forte garantia econômica após dois Epochs.
Nos últimos anos, as pessoas têm ficado cada vez mais insatisfeitas com este método, principalmente por duas razões: primeiro, a alta complexidade, existem muitos problemas de interação entre o mecanismo de votação de slot a slot e o mecanismo de finalização de Epoch a Epoch; segundo, o tempo de finalização de 12,8 minutos é demasiado longo.
A finalização de slot único (SSF) substituiu essa arquitetura por meio de um mecanismo semelhante ao Tendermint, onde o bloco N pode ser finalizado antes da geração do bloco N+1. A principal diferença em relação ao Tendermint é a preservação do mecanismo de "vazamento inativo", que permite que a cadeia continue funcionando e se recupere mesmo quando mais de 1/3 dos validadores estão offline.
O principal desafio do SSF é que cada participante deve publicar duas mensagens a cada 12 segundos, o que traz uma grande carga para a cadeia. Embora haja algumas soluções de mitigação, como a recente proposta Orbit SSF, isso não alterou o fato de que os usuários precisam esperar entre 5 a 20 segundos.
Pré-confirmação de Rollup
Ethereum tem seguido nos últimos anos um roteiro centrado em rollups, projetando o L1 como uma camada base que suporta disponibilidade de dados e outras funcionalidades para uso por protocolos L2. Isso criou uma separação de preocupações dentro do ecossistema: o L1 foca em resistência à censura, confiabilidade e melhorias nas funcionalidades principais, enquanto o L2 atende mais diretamente às necessidades dos usuários.
Teoricamente, a criação de uma rede de ordenadores descentralizados é responsabilidade do L2. Um pequeno grupo de validadores pode assinar blocos a cada poucos centenas de milissegundos e publicar os cabeçalhos desses blocos no L1. No entanto, exigir que todos os L2 realizem uma ordenação descentralizada parece um tanto injusto, pois isso equivale a criar um novo L1.
Confirmação Prévia Básica
A hipótese básica de pré-confirmação assume que os proponentes do Ethereum são participantes MEV altamente complexos. Este método utiliza essa complexidade incentivando esses proponentes a aceitarem a responsabilidade de fornecer serviços de pré-confirmação.
A ideia básica é criar um protocolo padronizado, onde os usuários podem pagar uma taxa adicional para obter a garantia imediata de que a transação será incluída no próximo bloco, bem como uma declaração sobre o resultado da execução. Se o proponente violar a promessa, será penalizado.
Este mecanismo não se aplica apenas a transações L1, mas também pode fornecer pré-confirmações para rollups "baseados".
Perspectivas Futuras
Suponha que a finalização de um slot único tenha sido implementada e que técnicas semelhantes às do Orbit sejam utilizadas para reduzir o número de validadores por slot. A duração do slot pode aumentar para 16 segundos, e então usar a pré-confirmação de rollup ou a pré-confirmação básica para oferecer confirmações mais rápidas aos usuários. No final, poderemos obter uma arquitetura de epoch-slot.
A arquitetura epoch-slot parece ser inevitável, pois o tempo necessário para alcançar um consenso geral sobre algo é menor do que o necessário para alcançar um acordo de "finalidade econômica" máximo. As razões incluem o número de nós e a "qualidade" dos nós.
No atual Ethereum, um slot de 12 segundos é dividido em três sub-slots. Se o número de validadores for significativamente reduzido, pode ser reduzido para dois sub-slots e usar um tempo de slot de 8 segundos. Se depender de um subconjunto de nós especializados para alcançar um protocolo aproximado, pode ser ainda mais encurtado para cerca de 2 segundos.
Sugestões de Estratégia L2
Atualmente, existem três estratégias razoáveis para L2:
Tecnologicamente e espiritualmente "baseado" em Ethereum, otimizando suas propriedades técnicas fundamentais e valores.
Tornar-se um "servidor com estrutura de blockchain", aproveitando ao máximo a eficiência do servidor enquanto obtém os benefícios da cadeia.
Método de compromisso: uma cadeia rápida com cerca de cem nós, Ethereum oferece interoperabilidade e segurança adicionais.
Para algumas aplicações, um tempo de bloqueio de 12 segundos é suficiente. Para outras aplicações, a única solução é a arquitetura epoch-slot. A questão chave é quão bem a arquitetura epoch-slot nativa do Ethereum pode funcionar, o que afetará o significado de outras soluções.
Atualmente, ainda estamos longe das respostas finais para essas questões. A complexidade dos proponentes de blocos ainda apresenta uma grande incerteza. Projetos inovadores como o Orbit SSF merecem ser explorados mais a fundo. Quanto mais opções tivermos, melhor poderemos servir os usuários de L1 e L2, além de simplificar 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.
22 Curtidas
Recompensa
22
8
Repostar
Compartilhar
Comentário
0/400
ShibaMillionairen't
· 07-21 14:39
Negociação de criptomoedas é como sonambulismo, morri a rir. Espera, se o tempo de confirmação for curto, não é possível fazer as pessoas de parvas?
Ver originalResponder0
DefiPlaybook
· 07-20 15:55
É realmente absurdo, ou será que eu trabalhei a mais um pouco?
Ver originalResponder0
GasFeeCryer
· 07-20 01:55
A confirmação do L1 da antiga era é tão lenta que chega a ser de chorar. Agora, consegue-se usar com dificuldade.
Ver originalResponder0
CryptoTherapist
· 07-20 01:48
a ansiedade de negociação é real família... vamos meditar sobre esses tempos de confirmação e liberar a mentalidade de fomo para ser honesto
Ver originalResponder0
MissedTheBoat
· 07-20 01:47
Nem os cartões de crédito são assim tão enrolados... Acelera!
Ver originalResponder0
AllInAlice
· 07-20 01:46
Confirmação quase a voar, 5 segundos já é fantástico, está bem?
Ver originalResponder0
AirdropHunterZhang
· 07-20 01:28
Aconselho todos a não se apaixonarem pelo gás, se estiver baixo, Tudo em.
Ver originalResponder0
FUD_Vaccinated
· 07-20 01:26
Ri alto ainda se preocupando com isso, não é melhor L2?
Discussão sobre a otimização do tempo de confirmação de transações no Ethereum: comparação entre SSF, Rollup e soluções de pré-confirmação básicas
Discussão sobre soluções para otimizar o tempo de confirmação de transações no Ethereum
Um aspecto importante da experiência do usuário em blockchain é o rápido tempo de confirmação de transações. Nos últimos anos, o Ethereum fez progressos significativos nessa área. Graças ao EIP-1559 e à estabilidade do tempo de bloco após a transição para PoS, as transações enviadas pelos usuários na L1 geralmente podem ser confirmadas em 5 a 20 segundos, o que é basicamente equivalente à experiência de pagamento com cartão de crédito. No entanto, ainda é valioso melhorar ainda mais a experiência do usuário, pois algumas aplicações exigem até mesmo latências sub-segundo. Este artigo explorará algumas opções viáveis para o Ethereum melhorar o tempo de confirmação de transações.
Visão Geral da Tecnologia Existente
finalização de slot único
Atualmente, o consenso Gasper do Ethereum adota uma arquitetura de slot único e Epoch. A cada 12 segundos um slot, alguns validadores votam no cabeçalho da cadeia, e todos os validadores têm a oportunidade de votar uma vez em 32 slots. Esses votos são reinterpretados como mensagens semelhantes ao algoritmo de consenso PBFT, fornecendo uma finalização com forte garantia econômica após dois Epochs.
Nos últimos anos, as pessoas têm ficado cada vez mais insatisfeitas com este método, principalmente por duas razões: primeiro, a alta complexidade, existem muitos problemas de interação entre o mecanismo de votação de slot a slot e o mecanismo de finalização de Epoch a Epoch; segundo, o tempo de finalização de 12,8 minutos é demasiado longo.
A finalização de slot único (SSF) substituiu essa arquitetura por meio de um mecanismo semelhante ao Tendermint, onde o bloco N pode ser finalizado antes da geração do bloco N+1. A principal diferença em relação ao Tendermint é a preservação do mecanismo de "vazamento inativo", que permite que a cadeia continue funcionando e se recupere mesmo quando mais de 1/3 dos validadores estão offline.
O principal desafio do SSF é que cada participante deve publicar duas mensagens a cada 12 segundos, o que traz uma grande carga para a cadeia. Embora haja algumas soluções de mitigação, como a recente proposta Orbit SSF, isso não alterou o fato de que os usuários precisam esperar entre 5 a 20 segundos.
Pré-confirmação de Rollup
Ethereum tem seguido nos últimos anos um roteiro centrado em rollups, projetando o L1 como uma camada base que suporta disponibilidade de dados e outras funcionalidades para uso por protocolos L2. Isso criou uma separação de preocupações dentro do ecossistema: o L1 foca em resistência à censura, confiabilidade e melhorias nas funcionalidades principais, enquanto o L2 atende mais diretamente às necessidades dos usuários.
Teoricamente, a criação de uma rede de ordenadores descentralizados é responsabilidade do L2. Um pequeno grupo de validadores pode assinar blocos a cada poucos centenas de milissegundos e publicar os cabeçalhos desses blocos no L1. No entanto, exigir que todos os L2 realizem uma ordenação descentralizada parece um tanto injusto, pois isso equivale a criar um novo L1.
Confirmação Prévia Básica
A hipótese básica de pré-confirmação assume que os proponentes do Ethereum são participantes MEV altamente complexos. Este método utiliza essa complexidade incentivando esses proponentes a aceitarem a responsabilidade de fornecer serviços de pré-confirmação.
A ideia básica é criar um protocolo padronizado, onde os usuários podem pagar uma taxa adicional para obter a garantia imediata de que a transação será incluída no próximo bloco, bem como uma declaração sobre o resultado da execução. Se o proponente violar a promessa, será penalizado.
Este mecanismo não se aplica apenas a transações L1, mas também pode fornecer pré-confirmações para rollups "baseados".
Perspectivas Futuras
Suponha que a finalização de um slot único tenha sido implementada e que técnicas semelhantes às do Orbit sejam utilizadas para reduzir o número de validadores por slot. A duração do slot pode aumentar para 16 segundos, e então usar a pré-confirmação de rollup ou a pré-confirmação básica para oferecer confirmações mais rápidas aos usuários. No final, poderemos obter uma arquitetura de epoch-slot.
A arquitetura epoch-slot parece ser inevitável, pois o tempo necessário para alcançar um consenso geral sobre algo é menor do que o necessário para alcançar um acordo de "finalidade econômica" máximo. As razões incluem o número de nós e a "qualidade" dos nós.
No atual Ethereum, um slot de 12 segundos é dividido em três sub-slots. Se o número de validadores for significativamente reduzido, pode ser reduzido para dois sub-slots e usar um tempo de slot de 8 segundos. Se depender de um subconjunto de nós especializados para alcançar um protocolo aproximado, pode ser ainda mais encurtado para cerca de 2 segundos.
Sugestões de Estratégia L2
Atualmente, existem três estratégias razoáveis para L2:
Para algumas aplicações, um tempo de bloqueio de 12 segundos é suficiente. Para outras aplicações, a única solução é a arquitetura epoch-slot. A questão chave é quão bem a arquitetura epoch-slot nativa do Ethereum pode funcionar, o que afetará o significado de outras soluções.
Atualmente, ainda estamos longe das respostas finais para essas questões. A complexidade dos proponentes de blocos ainda apresenta uma grande incerteza. Projetos inovadores como o Orbit SSF merecem ser explorados mais a fundo. Quanto mais opções tivermos, melhor poderemos servir os usuários de L1 e L2, além de simplificar o trabalho dos desenvolvedores de L2.