Discussão de soluções práticas para melhorar o tempo de confirmação das transações Ethereum
Nos últimos anos, o Ethereum fez progressos significativos na velocidade de confirmação de transações. Graças ao EIP-1559 e à estabilidade do tempo de bloco após a transição para o mecanismo PoS, as transações enviadas pelos usuários na L1 podem geralmente ser confirmadas em 5 a 20 segundos, basicamente equivalente à experiência de pagamento com cartão de crédito. No entanto, ainda é valioso melhorar a experiência do usuário, e certas aplicações até exigem tempos de resposta em subsegundos. Este artigo explorará várias soluções viáveis para o Ethereum melhorar a velocidade de confirmação de transações.
Visão Geral da Tecnologia Atual
finalidade de slot único
Atualmente, o consenso Gasper do Ethereum adota uma arquitetura de slots e ciclos. A cada 12 segundos, um slot, onde alguns validadores votam no cabeçalho da cadeia, e todos os validadores têm a oportunidade de votar uma vez dentro de 32 slots (6,4 minutos). Esses votos são interpretados como mensagens no algoritmo de consenso tipo PBFT, e após dois ciclos (12,8 minutos), fornece uma finalização com fortes garantias econômicas.
Esta abordagem apresenta dois problemas principais: primeiro, a complexidade é alta, existem muitos problemas de interação entre o mecanismo de votação de slot para slot e o mecanismo de finalização de ciclo para ciclo; segundo, o tempo de confirmação final de 12,8 minutos é demasiado longo e não corresponde às expectativas dos usuários.
A finalização de slot único (SSF) substitui essa arquitetura por meio de um mecanismo semelhante ao Tendermint, onde o bloco N pode alcançar a confirmação final antes da geração do bloco N+1. O SSF mantém o mecanismo de "vazamento inativo", permitindo 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 validor deve publicar duas mensagens a cada 12 segundos, o que representa uma enorme carga para a cadeia. Embora existam algumas soluções de mitigação, como a recente proposta Orbit SSF, os usuários ainda precisam esperar de 5 a 20 segundos para confirmar uma transação.
Pré-confirmação do Rollup
Ethereum tem seguido, nos últimos anos, um roteiro centrado em rollups, projetando o L1 como uma camada base que suporta a disponibilidade de dados e outras funcionalidades, para ser utilizada por protocolos L2 (como rollups, validiums e plasmas), oferecendo serviços com segurança equivalente à do Ethereum em maior escala.
Isto levou à separação dos pontos de atenção dentro do ecossistema Ethereum: L1 foca na resistência à censura, confiabilidade e estabilidade, bem como na manutenção e melhoria das funcionalidades principais; L2, por outro lado, serve os usuários de forma mais direta através de diferentes culturas e tecnologias. No entanto, L2 deseja oferecer aos usuários tempos de confirmação mais rápidos do que 5-20 segundos.
Em teoria, a criação de uma rede de ordenadores descentralizada é responsabilidade do L2. Um pequeno grupo de validadores pode assinar blocos a cada algumas centenas de milissegundos e apostar ativos como garantia. Esses cabeçalhos de blocos L2 acabarão por ser publicados no L1.
No entanto, exigir que todos os L2 implementem uma ordenação descentralizada parece um pouco injusto, pois equivale a exigir que um rollup realize um trabalho quase idêntico ao de criar um novo L1. Assim, foi proposta a ideia de fazer com que todos os L2 (e L1) compartilhem um mecanismo de pré-confirmação dentro do âmbito do Ethereum: pré-confirmação básica.
Pré-confirmação básica
O método básico de pré-confirmação assume que os proponentes do Ethereum são participantes complexos relacionados ao MEV. Ele aproveita essa complexidade incentivando esses proponentes a aceitarem a responsabilidade de fornecer serviços de pré-confirmação.
Este método cria um protocolo padronizado, onde os usuários podem pagar uma taxa adicional para obter uma garantia instantânea de que a transação será incluída no próximo bloco, bem como um compromisso com o resultado da execução dessa transação. Se o proponente violar o compromisso, ele enfrentará penalidades.
Este mecanismo não se aplica apenas a transações L1, mas para rollups "baseados" em Ethereum, todos os blocos L2 são na verdade transações L1, portanto, o mesmo mecanismo pode fornecer serviços de pré-confirmação para qualquer L2.
Arquitetura potencial futura
Suponha que implementemos a finalização de um único slot e utilizemos uma tecnologia semelhante ao Orbit para reduzir o número de validadores que assinam em cada slot, mantendo ao mesmo tempo descentralização suficiente para diminuir a barreira de entrada para staking. A duração do slot pode aumentar para 16 segundos, e então usamos pré-confirmações de rollup ou pré-confirmações básicas para oferecer confirmações mais rápidas aos usuários. No final, obtemos uma arquitetura de ciclo-slot.
A razão pela qual essa arquitetura é difícil de evitar é porque o tempo necessário para alcançar um consenso geral sobre algo é muito menor do que o tempo necessário para alcançar o nível máximo de "finalidade econômica". As razões incluem:
"Consenso aproximado" requer apenas um pequeno número de nós, enquanto a finalidade econômica necessita da participação da maioria dos nós.
Depois que o número de nós ultrapassa um certo tamanho, o tempo necessário para coletar assinaturas aumentará significativamente.
No atual Ethereum, o slot de 12 segundos é dividido em três sub-slots: publicação e distribuição de blocos, prova, agregação de provas. Se reduzirmos drasticamente o número de provedores, podemos reduzir para dois sub-slots, alcançando um tempo de slot de 8 segundos. Se conseguirmos depender de um subconjunto de nós especializados para alcançar um protocolo aproximado (enquanto ainda usamos o conjunto completo de validadores para determinar a finalização), podemos até reduzir o tempo para cerca de 2 segundos.
Portanto, a arquitetura de ciclo-slot parece ser inevitável, mas existem diferenças entre as diferentes implementações. Uma direção que vale a pena explorar é estabelecer um maior grau de separação de preocupações entre os dois mecanismos, em vez de estar fortemente acoplado como o Gasper.
Seleção de Estratégia L2
Atualmente, existem três estratégias razoáveis para L2:
Em termos técnicos e de conceito, são "baseados" em Ethereum. Esses rollups podem ser vistos como "shards de marca", e também podem realizar muitos experimentos em novos designs de máquinas virtuais e outras melhorias tecnológicas.
Tornar-se um "servidor com estrutura de blockchain". Obtendo a maior parte dos benefícios de estar na cadeia através da adição de provas de validade STARK, garantindo os direitos de saída dos usuários, apoiando a escolha coletiva, etc., enquanto mantém a vantagem de eficiência do servidor.
Método de compromisso: estabelecer uma cadeia rápida com cem nós, ao mesmo tempo que se aproveita o Ethereum para fornecer interoperabilidade e segurança adicionais. Este é o roteiro prático atual de muitos projetos L2.
Para certas aplicações (como ENS, armazenamento de chaves, alguns protocolos de pagamento), um tempo de bloco de 12 segundos já é suficiente. Para outras aplicações, a única solução é a arquitetura de ciclo-slot. Nesta arquitetura, "ciclo" é o SSF do Ethereum, enquanto "slot" varia em diferentes situações:
Arquitetura de ciclo-slot nativa do Ethereum
Pré-confirmação do servidor
Pré-confirmação do Comitê
A questão chave é quão bem a primeira proposta pode ser implementada. Se ela se sair bem, o significado da terceira proposta será reduzido. A segunda proposta sempre existirá, pois todas as soluções "baseadas" em Ethereum não são aplicáveis a dados off-chain L2, como plasmas e validiums. Se a arquitetura nativa de ciclos e slots do Ethereum puder reduzir o tempo dos slots para 1 segundo, o espaço para a terceira proposta será significativamente diminuído.
Atualmente, estamos longe das respostas finais para essas questões. Uma incerteza chave é quão complexos se tornarão os proponentes de blocos. Designs inovadores como o Orbit SSF nos oferecem mais espaço para exploração, como usar o Orbit SSF como um período na arquitetura de períodos e slots. Quanto mais opções tivermos, melhor poderemos servir os usuários de L1 e L2, ao mesmo tempo que simplificamos 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.
16 Curtidas
Recompensa
16
5
Compartilhar
Comentário
0/400
¯\_(ツ)_/¯
· 11h atrás
Essa velocidade é pior que a do pow?
Ver originalResponder0
LightningAllInHero
· 08-02 19:40
Ainda a mexer na velocidade de confirmação... não serve de nada.
Ver originalResponder0
rekt_but_resilient
· 08-02 19:33
L2 é para ser mais rápido.
Ver originalResponder0
ValidatorViking
· 08-02 19:30
estes tempos de finalização ainda fazem ragnarök parecer rápido... a infraestrutura do nó precisa de testes de batalha sérios antes de quaisquer ajustes de consenso sofisticados, para ser sincero.
Solução para acelerar a confirmação de transações do Ethereum: uma discussão abrangente sobre SSF até pré-confirmação L2
Discussão de soluções práticas para melhorar o tempo de confirmação das transações Ethereum
Nos últimos anos, o Ethereum fez progressos significativos na velocidade de confirmação de transações. Graças ao EIP-1559 e à estabilidade do tempo de bloco após a transição para o mecanismo PoS, as transações enviadas pelos usuários na L1 podem geralmente ser confirmadas em 5 a 20 segundos, basicamente equivalente à experiência de pagamento com cartão de crédito. No entanto, ainda é valioso melhorar a experiência do usuário, e certas aplicações até exigem tempos de resposta em subsegundos. Este artigo explorará várias soluções viáveis para o Ethereum melhorar a velocidade de confirmação de transações.
Visão Geral da Tecnologia Atual
finalidade de slot único
Atualmente, o consenso Gasper do Ethereum adota uma arquitetura de slots e ciclos. A cada 12 segundos, um slot, onde alguns validadores votam no cabeçalho da cadeia, e todos os validadores têm a oportunidade de votar uma vez dentro de 32 slots (6,4 minutos). Esses votos são interpretados como mensagens no algoritmo de consenso tipo PBFT, e após dois ciclos (12,8 minutos), fornece uma finalização com fortes garantias econômicas.
Esta abordagem apresenta dois problemas principais: primeiro, a complexidade é alta, existem muitos problemas de interação entre o mecanismo de votação de slot para slot e o mecanismo de finalização de ciclo para ciclo; segundo, o tempo de confirmação final de 12,8 minutos é demasiado longo e não corresponde às expectativas dos usuários.
A finalização de slot único (SSF) substitui essa arquitetura por meio de um mecanismo semelhante ao Tendermint, onde o bloco N pode alcançar a confirmação final antes da geração do bloco N+1. O SSF mantém o mecanismo de "vazamento inativo", permitindo 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 validor deve publicar duas mensagens a cada 12 segundos, o que representa uma enorme carga para a cadeia. Embora existam algumas soluções de mitigação, como a recente proposta Orbit SSF, os usuários ainda precisam esperar de 5 a 20 segundos para confirmar uma transação.
Pré-confirmação do Rollup
Ethereum tem seguido, nos últimos anos, um roteiro centrado em rollups, projetando o L1 como uma camada base que suporta a disponibilidade de dados e outras funcionalidades, para ser utilizada por protocolos L2 (como rollups, validiums e plasmas), oferecendo serviços com segurança equivalente à do Ethereum em maior escala.
Isto levou à separação dos pontos de atenção dentro do ecossistema Ethereum: L1 foca na resistência à censura, confiabilidade e estabilidade, bem como na manutenção e melhoria das funcionalidades principais; L2, por outro lado, serve os usuários de forma mais direta através de diferentes culturas e tecnologias. No entanto, L2 deseja oferecer aos usuários tempos de confirmação mais rápidos do que 5-20 segundos.
Em teoria, a criação de uma rede de ordenadores descentralizada é responsabilidade do L2. Um pequeno grupo de validadores pode assinar blocos a cada algumas centenas de milissegundos e apostar ativos como garantia. Esses cabeçalhos de blocos L2 acabarão por ser publicados no L1.
No entanto, exigir que todos os L2 implementem uma ordenação descentralizada parece um pouco injusto, pois equivale a exigir que um rollup realize um trabalho quase idêntico ao de criar um novo L1. Assim, foi proposta a ideia de fazer com que todos os L2 (e L1) compartilhem um mecanismo de pré-confirmação dentro do âmbito do Ethereum: pré-confirmação básica.
Pré-confirmação básica
O método básico de pré-confirmação assume que os proponentes do Ethereum são participantes complexos relacionados ao MEV. Ele aproveita essa complexidade incentivando esses proponentes a aceitarem a responsabilidade de fornecer serviços de pré-confirmação.
Este método cria um protocolo padronizado, onde os usuários podem pagar uma taxa adicional para obter uma garantia instantânea de que a transação será incluída no próximo bloco, bem como um compromisso com o resultado da execução dessa transação. Se o proponente violar o compromisso, ele enfrentará penalidades.
Este mecanismo não se aplica apenas a transações L1, mas para rollups "baseados" em Ethereum, todos os blocos L2 são na verdade transações L1, portanto, o mesmo mecanismo pode fornecer serviços de pré-confirmação para qualquer L2.
Arquitetura potencial futura
Suponha que implementemos a finalização de um único slot e utilizemos uma tecnologia semelhante ao Orbit para reduzir o número de validadores que assinam em cada slot, mantendo ao mesmo tempo descentralização suficiente para diminuir a barreira de entrada para staking. A duração do slot pode aumentar para 16 segundos, e então usamos pré-confirmações de rollup ou pré-confirmações básicas para oferecer confirmações mais rápidas aos usuários. No final, obtemos uma arquitetura de ciclo-slot.
A razão pela qual essa arquitetura é difícil de evitar é porque o tempo necessário para alcançar um consenso geral sobre algo é muito menor do que o tempo necessário para alcançar o nível máximo de "finalidade econômica". As razões incluem:
No atual Ethereum, o slot de 12 segundos é dividido em três sub-slots: publicação e distribuição de blocos, prova, agregação de provas. Se reduzirmos drasticamente o número de provedores, podemos reduzir para dois sub-slots, alcançando um tempo de slot de 8 segundos. Se conseguirmos depender de um subconjunto de nós especializados para alcançar um protocolo aproximado (enquanto ainda usamos o conjunto completo de validadores para determinar a finalização), podemos até reduzir o tempo para cerca de 2 segundos.
Portanto, a arquitetura de ciclo-slot parece ser inevitável, mas existem diferenças entre as diferentes implementações. Uma direção que vale a pena explorar é estabelecer um maior grau de separação de preocupações entre os dois mecanismos, em vez de estar fortemente acoplado como o Gasper.
Seleção de Estratégia L2
Atualmente, existem três estratégias razoáveis para L2:
Em termos técnicos e de conceito, são "baseados" em Ethereum. Esses rollups podem ser vistos como "shards de marca", e também podem realizar muitos experimentos em novos designs de máquinas virtuais e outras melhorias tecnológicas.
Tornar-se um "servidor com estrutura de blockchain". Obtendo a maior parte dos benefícios de estar na cadeia através da adição de provas de validade STARK, garantindo os direitos de saída dos usuários, apoiando a escolha coletiva, etc., enquanto mantém a vantagem de eficiência do servidor.
Método de compromisso: estabelecer uma cadeia rápida com cem nós, ao mesmo tempo que se aproveita o Ethereum para fornecer interoperabilidade e segurança adicionais. Este é o roteiro prático atual de muitos projetos L2.
Para certas aplicações (como ENS, armazenamento de chaves, alguns protocolos de pagamento), um tempo de bloco de 12 segundos já é suficiente. Para outras aplicações, a única solução é a arquitetura de ciclo-slot. Nesta arquitetura, "ciclo" é o SSF do Ethereum, enquanto "slot" varia em diferentes situações:
A questão chave é quão bem a primeira proposta pode ser implementada. Se ela se sair bem, o significado da terceira proposta será reduzido. A segunda proposta sempre existirá, pois todas as soluções "baseadas" em Ethereum não são aplicáveis a dados off-chain L2, como plasmas e validiums. Se a arquitetura nativa de ciclos e slots do Ethereum puder reduzir o tempo dos slots para 1 segundo, o espaço para a terceira proposta será significativamente diminuído.
Atualmente, estamos longe das respostas finais para essas questões. Uma incerteza chave é quão complexos se tornarão os proponentes de blocos. Designs inovadores como o Orbit SSF nos oferecem mais espaço para exploração, como usar o Orbit SSF como um período na arquitetura de períodos e slots. Quanto mais opções tivermos, melhor poderemos servir os usuários de L1 e L2, ao mesmo tempo que simplificamos o trabalho dos desenvolvedores de L2.