Com todos a afirmarem que conseguem tempos de bloco cada vez mais baixos nos L2s, achei que era altura de descrever o que se passa. Especificamente, vamos verificar o que são blocos L2, como diferem dos blocos L1 e por que realmente não devemos preocupar-nos muito com os tempos de bloco L2, mesmo que sejam uma métrica de engenharia interessante.

O que é um bloco?

Na época em que o termo blockchain realmente significava algo (cerca de 2009), o conceito de blocos foi introduzido porque precisávamos de uma unidade para um grupo de transações submetidas ao consenso.

Por exemplo, no Bitcoin, cada produtor de bloco tenta encontrar uma disposição de transações que satisfaça os requisitos de PoW, e depois transmite este bloco para a rede. Outros nós verificarão se este bloco realmente cumpre os requisitos de PoW. No Ethereum, que agora é PoS e baseado em contas, os produtores de bloco calculam um hash do estado da blockchain após a execução de cada bloco (o compromisso do estado), e os validadores recalculam esse valor para facilitar a validação do bloco. O processo geral é sempre o mesmo:

1. Selecione algumas transações e ordene-as. Chame isso de bloco.
2. Calcular algumas métricas específicas (quebra-cabeça PoW, compromisso de estado). Anexar isso ao bloco.
3. Transmita este bloco + metadados para os outros nós na rede.
4. Outros nós recalculam os metadados e comparam o que foi calculado com os metadados enviados pelo produtor de bloco. Se corresponder, aceite o bloco.

Nas cadeias de camada-1, os blocos são importantes: você verifica a integridade da cadeia ao nível dos blocos, gere forks ao nível dos blocos, etc.

TL;DR: blocos são um elemento essencial do consenso.

O que é um bloco L2?

As L2 existem porque o consenso é lento e a descentralização requer suporte a computadores e redes lentas. A abordagem L2 descarrega o processamento de transações para a máquina mais rápida disponível e, em seguida, publica um resumo de execução verificável para L1 para consenso. Simplificando, a maioria dos L2s hoje são sistemas centralizados que fingem ser blockchains. E isso é perfeitamente aceitável.

É aqui que os tempos de bloco se tornam confusos. Os L2s continuam a construir blocos principalmente para a compatibilidade de software L1, mas é em grande parte artificial. Ao publicar resumos no L1, os L2s geralmente agrupam vários blocos juntos para reduzir custos. Embora os compromissos de estado sejam necessários ocasionalmente para provas de fraude/validade, não são necessários para cada bloco. Portanto, os blocos L2 são essencialmente inúteis.

Quando alguém afirma que tem blocos L2 rápidos, simplesmente ajustaram um valor de configuração do sistema para diminuir os tempos de bloco. Embora ainda precisem processar um número significativo de transações por bloco, isso é o limite.

O que importa então?

Como utilizador, preocupa-se com uma coisa em termos de tempo: o tempo de ida e volta. Em outras palavras, quanto tempo levará para a minha transação chegar ao sequenciador L2, ser executada e o resultado ser visível no nó RPC que estou a utilizar? Vamos focar-nos nessa última parte: quanto tempo demora a comunicar a execução de uma transação aos RPCs?

Blockchains mais lentas normalmente esperam pelo final de um bloco antes de enviá-lo para os pares. A Solana começou a ideia de que você poderia transmitir blocos em vez disso: basta enviar transações para os outros validadores assim que as processar. A Solana divide estas em entradas (grupos de no máximo 64 transações), que são por sua vez divididas em fragmentos para transferência na rede. Nós temos umartigo detalhadosobre este tópico, se estiver curioso. Estes são transmitidos continuamente a partir do nó líder para outros, o que significa que obtém informações sobre a execução das suas transações antes mesmo de o bloco terminar.

L2s agora decidiram reutilizar este mecanismo: Base, com Flashblocks, passa de um tempo de bloco de 2 segundos para sub-blocos menores de 200ms. MegaETH tem um conceito de "mini-blocos", produzidos a cada 15 ms na sua testnet (na maior parte do tempo). Eclipse utiliza o sistema de entrada/divisão Solana. Desta forma, os utilizadores têm de esperar menos para que as suas transações sejam executadas. Isso é bastante bom para a UX!

Mas vamos ser claros: a verdadeira funcionalidade aqui é a 'redução dos intervalos de comunicação em toda a rede'. Não tem nada a ver com alguns blocos serem inerentemente melhores do que outros. Apenas estamos a dividir os blocos em pedaços mais pequenos e a transmiti-los em paralelo com a execução. Se chamares a estes pedaços blocos, mini-blocos ou fragmentos, não importa. O objetivo final é uma comunicação mais rápida, não blocos melhores.

Aviso legal:

1. Este artigo é reimpresso de [GateOlivier]. Todos os direitos de autor pertencem ao autor original [Olivier]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Learnequipa e eles vão tratar do assunto prontamente.
2. Responsabilidade de Isenção de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. A equipa do Gate Learn faz traduções do artigo para outras línguas. É proibido copiar, distribuir ou plagiar os artigos traduzidos, a menos que seja mencionado.