Agradecimentos especiais a Jon Charbonneau e Conor McMenamin pela revisão deste artigo.

Neste ponto, todos devemos saber que as regras de confirmação têm segurança, e não os rollups em si. Quando dizemos que os rollups herdam a “segurança do Ethereum” ou que são “minimizados pela confiança”, o que na verdade queremos dizer é que nos rollups é possível usar regras de confirmação que tenham aproximadamente a mesma segurança que as regras de confirmação do Ethereum. Porém, os exploradores de bloco se preocupam principalmente em mostrar um emblema verde sem entrar em detalhes sobre a qual regra de confirmação eles estão se referindo ou quais propriedades de segurança eles fornecem.

Na L2BEAT queremos resolver este problema e torná-lo acessível a todos. Em particular, queremos focar na finalidade, a regra de confirmação mais forte contra ataques de gasto duplo.

Regras de confirmação: consistência vs disponibilidade

Regras de confirmação são algoritmos que, sob suposições específicas, indicam quando um bloco é confirmado e é improvável que seja reorganizado. Uma vez confirmado um bloco, ações relacionadas às suas transações podem ser tomadas. Por exemplo, isso pode envolver a entrega de um café a um cliente ou a entrega de um carro ao comprador.

Diferentes regras de confirmação oferecem aos usuários diferentes garantias de segurança. A segurança de uma regra de confirmação compreende consistência e disponibilidade e depende fortemente dos algoritmos de consenso subjacentes:

• Consistência (segurança): a visualização de quaisquer dois nós é consistente nas partições de rede.
• Disponibilidade (vivacidade): as transações continuam a ser incluídas no razão dentro de algum tempo, mesmo depois que uma fração substancial dos nós deixa de participar do protocolo.

O Teorema CAP nos diz que não é possível projetar um algoritmo de consenso que permaneça consistente sob partições de rede e disponível sob participação dinâmica: se ocorrer uma partição de rede séria, os nós podem decidir continuar a produzir blocos e perder consistência, ou parar e perder disponibilidade. Não há como os nós distinguirem entre outros que estão simplesmente offline (participação dinâmica) ou que estão ativos mas inacessíveis (partições de rede) e, portanto, não é possível agir de forma diferente.

Eve não consegue saber se Bob está simplesmente offline ou em uma partição de rede diferente.

Blockchains como o Bitcoin, utilizando um consenso semelhante ao de Nakamoto, favorecem a vivacidade, o que significa que durante uma divisão da rede, ambos os lados continuarão a produzir blocos e eventualmente serão reorganizados se a partição for resolvida, enquanto outros, como as cadeias Cosmos, usando um tipo PBFT. consenso, pare nas partições de rede para preservar a consistência.

Regras de confirmação no Ethereum

Ethereum prioriza a disponibilidade em partições de rede usando o algoritmo LMD GHOST . Essa abordagem significa que nós honestos podem ter visões diferentes na ponta da cadeia e confirmar blocos diferentes para a mesma altura, levando potencialmente a reorganizações.

Sob condições de rede favoráveis, o Ethereum também visa fornecer garantias de consistência por meio da finalidade, utilizando o protocolo Casper FFG . Finalidade é a regra de confirmação mais forte possível, com os nós tendo uma regra codificada para nunca reorganizar blocos finalizados.

O razão finalizado (verde) é sempre um prefixo do razão vivo (azul).

As garantias de finalidade são comprometidas se dois blocos conflitantes forem finalizados, um evento que pode ocorrer se mais de 1/3 dos validadores agirem de forma maliciosa. No entanto, no Ethereum, tais ações acarretam a penalidade significativa de perda da aposta.

Os usuários podem escolher se desejam usar o Casper FFG como a regra de confirmação mais segura ou ficar mais ativos contando com o LMD GHOST. As regras de confirmação para LMD GHOST, semelhantes à regra de confirmação k no Bitcoin, podem ser mais sofisticadas do que apenas verificar se a transação está incluída no livro-razão, conforme especificado na regra de confirmação do Bloqueio Seguro.

Regras de confirmação em rollups

Os rollups podem, em princípio, usar as mesmas regras de confirmação disponíveis no Ethereum. Se você enviar uma transação em um rollup e posteriormente vir a mesma transação lançada em L1 em um bloco finalizado, talvez você também queira considerar a transação L2 como final. Acontece que a história é muito mais complexa do que isso.

Rollups de dados de transação

No Ethereum, os blocos incluem a lista de transações e a raiz de estado proposta no cabeçalho do bloco. Se a execução das transações não levar ao estado que a raiz representa, todo o bloco é descartado, inclusive as transações que podem ser posteriormente adicionadas a outros blocos em uma ordem diferente.

Nos rollups, como as ações de publicação de dados e raízes são desacopladas, as transações não precisam ser descartadas dependendo da validade das raízes de estado correspondentes. Dada esta separação, é suficiente verificar se as transações são finalizadas sem esperar pela finalização da raiz estatal, contornando atrasos adicionais, como o período de desafio de 7 dias em rollups otimistas.

Acúmulo de diferenças de estado

As diferenças de estado são resultados de uma função de transição de estado e, para validar se são realmente válidas, é necessário aguardar uma prova ZK. A geração de provas ZK leva tempo e, além disso, há um incentivo para atrasar ainda mais a inclusão de mais transações em uma única prova, a fim de amortizar melhor os custos de geração e verificação de provas.

As técnicas de agregação de provas oferecem uma solução para esse compromisso entre tempos de confirmação e amortização de custos: mesmo que um rollup experimente atividade mínima, ele ainda pode se beneficiar da amortização ao incluir transações de rollups mais ativos na mesma prova. Um exemplo dessa abordagem é o SHARP da Starkware, atualmente agregando provas de rollups Starknet, Paradex e StarkEx como dYdX e até mesmo Validiums.

Onde as coisas ficam complicadas

Especificação de derivação de rollup

Se um rollup não for baseado, a ordem de derivação dos lotes pode ser definida pelo sequenciador de rollup, que pode publicá-los em uma ordem diferente em L1.

Para fornecer um exemplo, as cadeias OP Stack publicam lotes em L1 que são vinculados usando os hashes do lote anterior. Esses lotes não precisam ser publicados em ordem cronológica, levando a uma janela de sequenciamento de 12 horas durante a qual os nós aguardam por transações potencialmente perdidas. As transações não devem ser consideradas incluídas apenas porque são publicadas em L1: se um lote ainda não estiver conectado à cadeia canônica de lotes, existe o risco de que seja construído um fork alternativo com uma ordem ou conjunto de transações diferente.

Nas cadeias OP Stack, o tempo de bloqueio é de 2 segundos, resultando em 6 blocos dentro de cada bloco Ethereum. Este agrupamento de 6 blocos entre blocos Ethereum é denominado “época”. As mensagens L1 para L2 enviadas via L1 são incluídas na primeira parte do primeiro bloco da época correspondente para o bloco L1 fornecido. Embora essas transações possam ser consideradas confirmadas sem esperar a passagem da janela de sequenciamento, como sua ordem no livro-razão L2 na derivação é conhecida, é importante observar que os nós não começarão a computar blocos contendo essas mensagens se um lote anterior estiver faltando. Isto ocorre porque o estado não pode ser calculado sem a sequência completa e, portanto, as raízes do estado também não serão publicadas em L1.

A consequência disso é que apenas examinar os dados na cadeia é insuficiente para rastrear os tempos de confirmação L1. Também é necessário entender como os blocos L2 são derivados dos dados L1 examinando o próprio software do nó rollup.

Funções permitidas

Scroll é um rollup ZK que publica dados de transação, o que significa que, em princípio, não é necessário esperar por uma prova ZK para considerar sua transação final. Isso teria sido verdade se eles não tivessem implementado uma função para excluir lotes que ainda não foram comprovados.

https://etherscan.io/address/0x2e07f0fba71709bb5e1f045b02152e45b451d75f#code#F1#L260

O mesmo pode se aplicar a rollups que postam diferenças de estado: zkSync Era e zkSync Lite têm um processo de três etapas para postar diferenças de estado: primeiro, eles confirmam os dados sem qualquer prova, depois fornecem uma prova para eles e, em seguida, após um atraso de 24 horas , a raiz fica disponível para ser executada para processar retiradas. Em teoria, quando uma prova é fornecida, a ordem das transações é fixa, portanto não é necessário esperar que o atraso na execução passe. Exceto que o zkSync pode reverter esses bloqueios:

https://etherscan.io/address/0x7Ed066718Dfb1b2B04D94780Eca92b67ECF3330b#code#F10#L425

Embora no zkSync Era nenhum bloco tenha sido revertido, no zkSync Lite isso aconteceu 8 vezes.

Observabilidade de finalidade

Como as diferenças de estado de lançamento de rollup não estão lançando dados de transação, como podemos rastrear se uma transação foi realmente incluída? Sim, poderíamos rastrear efeitos, como nonces de contas, mas o caso geral fica complicado. Há um mês fiz a seguinte pergunta:

Vejamos algumas das respostas:

Esta é uma solução que funciona se o sequenciador estiver disposto a responder a você e se você confiar nele. E se isso não acontecer? Ou, e se acontecer, mas você não confia? Como você verifica se a afirmação está correta?

Minha resposta favorita.

Uma solução que realmente funciona foi sugerida aqui:

embora isso funcione, significa que a decisão técnica de usar diferenças de estado vaza para a lógica do aplicativo, o que significa que mesmo que um rollup seja equivalente a EVM, os projetos devem adaptar seu contrato a essa consideração.

Uma solução parcial é postar uma raiz de transações e verificar sua validade dentro da prova ZK. Mesmo neste caso, porém, é preciso confiar no sequenciador para obter o caminho Merkle necessário, o que pode ser razoável com sequenciadores centralizados confiáveis, mas fica mais complicado em um ambiente sem permissão.

Métricas de vivacidade

Como primeiro passo para rastrear os tempos até a finalização das transações de rollup, no L2BEAT começamos a monitorar as métricas de atividade, em particular os intervalos entre lotes de transações (se aplicável) e raízes de estado. A justificativa é que se um rollup estiver, por exemplo, interagindo com L1 apenas uma vez por mês, os usuários não podem esperar que o tempo até a finalização seja da ordem de minutos. As métricas de atividade podem ser pensadas como um indicador de limite inferior do tempo até a finalização: se um rollup de dados de transação estiver postando lotes uma vez a cada dois minutos e assumindo que a distribuição das transações L2 é uniforme, o tempo esperado até a finalização não será inferior a um minuto .

Aqui estão alguns exemplos de dados que estamos rastreando para zkSync Era (atualizações de estado) e OP Mainnet (lotes tx):

Métricas de atividade da Era zkSync para o mês de setembro.

Métricas de atividade da OP Mainnet para o mês de setembro.

Conforme previsto, como as provas ZK demoram para serem geradas e há o incentivo para incluir mais transações em uma única prova, o zkSync Era tem métricas de atividade piores do que o OP Mainnet. É importante ter em mente que, como discutimos nas seções anteriores, as métricas de atividade não se traduzem diretamente em considerações de finalidade: na pior das hipóteses, a OP Mainnet tem, na verdade, um tempo maior para conclusão devido à sua janela de sequenciamento.

Agora você pode explorar métricas de vivacidade para a maioria dos rollups no L2BEAT:

Limitações do rastreamento de atividade

Embora a vivacidade possa ser vista como um indicador de limite inferior de finalidade, às vezes pode ser um indicador muito ruim. Imagine um rollup com um tempo de bloco de 4 segundos, o que significa que para cada bloco Ethereum existem 3 blocos rollup. Se o operador de rollup postar apenas dois blocos L2 por bloco L1, mesmo que da perspectiva do Ethereum o rollup seja muito ativo, ele ficará cada vez mais atrás das confirmações suaves de L2 e o tempo até a finalização ficará cada vez pior. Embora este seja um cenário extremo, é algo que os rollups precisam levar em conta.

Um exemplo prático é o Starknet: embora observemos uma média de 32 segundos entre as atualizações de estado, o tempo até a finalização é na verdade próximo de 6 horas:

Fonte: starkscan.co

Isso ocorre porque Starknet publica uma atualização raiz de estado para cada bloco L2 em L1. No entanto, para fazer isso, eles devem fazer referência a uma prova SHARP, que normalmente é publicada aproximadamente uma vez a cada 30 minutos. Além disso, essas provas estão cerca de 6 horas atrás do final da cadeia L2 com confirmação suave.

Confirmações suaves

As confirmações suaves são regras de confirmação usadas para obter tempos de confirmação mais curtos em L2 em detrimento das garantias de segurança. Atualmente, em todos os casos, as confirmações suaves implicam confiar no operador centralizado para não postar diferentes txs em L1. Confirmações suaves incorretas são falhas atribuíveis, portanto, mecanismos para rastrear a reputação dos sequenciadores fora da cadeia ou cortes na cadeia podem ser implementados. Em colaboração com a Nethermind, planejamos estimar essas propriedades de segurança e rastrear a quantidade de valor em risco a qualquer momento.

Esquerda: garantias económicas na Starknet se tivessem confirmações suaves garantidas por um mecanismo de corte. Certo: valor total em risco de ser reorganizado ao longo do tempo.

Daqui para frente

Acompanhar o tempo até a finalização é uma tarefa complexa. Nosso primeiro passo é monitorar os intervalos de envios de provas para rollups ZK, que impõem um limite inferior mais alto no tempo até a finalização em comparação com os intervalos entre os envios raiz do estado. Em seguida, planejamos apresentar gráficos exibindo dados históricos de cada projeto. Posteriormente, nossa pesquisa se concentrará em todos os mecanismos adicionais que precisam ser considerados para, em última instância, alcançar métricas em tempo real até a finalização. Fique atento!

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [meio]. Todos os direitos autorais pertencem ao autor original [Luca Donno]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.