Com todos afirmando que estão conseguindo tempos de bloco cada vez menores nas L2s, achei que era hora de descrever o que está acontecendo. Especificamente, vamos verificar o que são os blocos L2, como eles diferem dos blocos L1 e por que realmente não devemos nos preocupar tanto com os tempos de bloco L2, mesmo que sejam uma métrica de engenharia interessante.
Lá atrás, quando o termo blockchain realmente significava algo (por volta 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 um arranjo de transações que satisfaça os requisitos de PoW, e depois transmite esse bloco para a rede. Outros nós verificarão se esse bloco realmente satisfaz os requisitos de PoW. No Ethereum, que agora é PoS e baseado em contas, os produtores de bloco calculam um hash do estado do 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:
Nas cadeias de camada-1, os blocos importam: você verifica a integridade da cadeia no nível dos blocos, gerencia forks no nível dos blocos, etc.
TL;DR: blocos são um primitivo essencial do consenso.
L2s existem porque o consenso é lento e a descentralização requer suporte a computadores e redes lentos. A abordagem L2 transfere 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. Em poucas palavras, a maioria dos L2s hoje são sistemas centralizados que fingem ser blockchains. E isso é perfeitamente normal.
Aqui é onde os tempos de bloco ficam confusos. L2s continuam a construir blocos principalmente para compatibilidade de software L1, mas é em grande parte artificial. Ao postar resumos para L1, L2s geralmente agrupam vários blocos juntos para reduzir custos. Embora compromissos de estado sejam necessários ocasionalmente para provas de fraude/validade, eles 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, eles 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 máximo.
Como usuário, você se preocupa com uma coisa, em termos de timing: o tempo de ida e volta. Em outras palavras, quanto tempo levará para minha transação chegar ao sequenciador L2, ser executada e o resultado ser visível no nó RPC que estou usando? Vamos nos concentrar nessa última parte: quanto tempo leva para comunicar a execução de uma transação para RPCs?
Blockchains mais lentas geralmente esperam o fim de um bloco antes de enviá-lo aos pares. A Solana começou com a ideia de que você poderia transmitir blocos em vez disso: basta enviar transações para os outros validadores assim que você as processou. A Solana divide essas em entradas (grupos de no máximo 64 transações), que são divididas em fragmentos para transferência na rede. Temos umartigo detalhadosobre este tópico se você está curioso. Estes são transmitidos continuamente do nó líder para outros, o que significa que você obtém informações sobre a execução de suas transações antes mesmo do bloco terminar.
L2s agora decidiram reutilizar esse mecanismo: Base, com Flashblocks, passa de um tempo de bloco de 2 segundos para sub-blocos menores de 200ms. O MegaETH tem um conceito de "mini-blocos", produzidos a cada 15 ms em sua testnet (na maior parte do tempo). O Eclipse usa o sistema de entrada/fragmentação da Solana. Dessa forma, os usuários têm que esperar menos para que suas transações sejam executadas. Isso é muito bom para a experiência do usuário!
Mas vamos ser claros: a verdadeira característica aqui é "intervalos reduzidos de comunicação em toda a rede." Não tem nada a ver com alguns blocos sendo inerentemente melhores do que outros. Apenas estamos dividindo os blocos em pedaços menores e transmitindo-os em paralelo com a execução. Se você chama esses pedaços de blocos, mini-blocos ou fragmentos, não importa. O objetivo final é uma comunicação mais rápida, não blocos melhores.
Compartir
Com todos afirmando que estão conseguindo tempos de bloco cada vez menores nas L2s, achei que era hora de descrever o que está acontecendo. Especificamente, vamos verificar o que são os blocos L2, como eles diferem dos blocos L1 e por que realmente não devemos nos preocupar tanto com os tempos de bloco L2, mesmo que sejam uma métrica de engenharia interessante.
Lá atrás, quando o termo blockchain realmente significava algo (por volta 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 um arranjo de transações que satisfaça os requisitos de PoW, e depois transmite esse bloco para a rede. Outros nós verificarão se esse bloco realmente satisfaz os requisitos de PoW. No Ethereum, que agora é PoS e baseado em contas, os produtores de bloco calculam um hash do estado do 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:
Nas cadeias de camada-1, os blocos importam: você verifica a integridade da cadeia no nível dos blocos, gerencia forks no nível dos blocos, etc.
TL;DR: blocos são um primitivo essencial do consenso.
L2s existem porque o consenso é lento e a descentralização requer suporte a computadores e redes lentos. A abordagem L2 transfere 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. Em poucas palavras, a maioria dos L2s hoje são sistemas centralizados que fingem ser blockchains. E isso é perfeitamente normal.
Aqui é onde os tempos de bloco ficam confusos. L2s continuam a construir blocos principalmente para compatibilidade de software L1, mas é em grande parte artificial. Ao postar resumos para L1, L2s geralmente agrupam vários blocos juntos para reduzir custos. Embora compromissos de estado sejam necessários ocasionalmente para provas de fraude/validade, eles 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, eles 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 máximo.
Como usuário, você se preocupa com uma coisa, em termos de timing: o tempo de ida e volta. Em outras palavras, quanto tempo levará para minha transação chegar ao sequenciador L2, ser executada e o resultado ser visível no nó RPC que estou usando? Vamos nos concentrar nessa última parte: quanto tempo leva para comunicar a execução de uma transação para RPCs?
Blockchains mais lentas geralmente esperam o fim de um bloco antes de enviá-lo aos pares. A Solana começou com a ideia de que você poderia transmitir blocos em vez disso: basta enviar transações para os outros validadores assim que você as processou. A Solana divide essas em entradas (grupos de no máximo 64 transações), que são divididas em fragmentos para transferência na rede. Temos umartigo detalhadosobre este tópico se você está curioso. Estes são transmitidos continuamente do nó líder para outros, o que significa que você obtém informações sobre a execução de suas transações antes mesmo do bloco terminar.
L2s agora decidiram reutilizar esse mecanismo: Base, com Flashblocks, passa de um tempo de bloco de 2 segundos para sub-blocos menores de 200ms. O MegaETH tem um conceito de "mini-blocos", produzidos a cada 15 ms em sua testnet (na maior parte do tempo). O Eclipse usa o sistema de entrada/fragmentação da Solana. Dessa forma, os usuários têm que esperar menos para que suas transações sejam executadas. Isso é muito bom para a experiência do usuário!
Mas vamos ser claros: a verdadeira característica aqui é "intervalos reduzidos de comunicação em toda a rede." Não tem nada a ver com alguns blocos sendo inerentemente melhores do que outros. Apenas estamos dividindo os blocos em pedaços menores e transmitindo-os em paralelo com a execução. Se você chama esses pedaços de blocos, mini-blocos ou fragmentos, não importa. O objetivo final é uma comunicação mais rápida, não blocos melhores.