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, não os rollups em si. Quando dizemos que os rollups herdam a “segurança Ethereum” ou que são “minimizados pela confiança”, o que realmente queremos dizer é que nos rollups é possível usar regras de confirmação que têm aproximadamente a mesma segurança que as regras de confirmação do Ethereum. Bloqueie exploradores, porém, preocupam-se principalmente em mostrar um crachá verde sem entrar nos detalhes sobre a regra de confirmação a que se referem ou quais propriedades de segurança fornecem.

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

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

As 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 bloqueio, podem ser tomadas ações relacionadas com as suas transações. Por exemplo, isto pode envolver a entrega de um café a um cliente ou a entrega de um carro ao seu comprador.

Diferentes regras de confirmação dão aos utilizadores diferentes garantias de segurança. A segurança de uma regra de confirmação compreende consistência e disponibilidade, e depende muito dos algoritmos de consenso subjacentes:

• Consistência (segurança): quaisquer dois pontos de vista são consistentes nas partições de rede.
• Disponibilidade (vida): as transações continuam a ser incluídas no livro-razão dentro de algum tempo limite, mesmo depois de uma fração substancial dos nós deixar de participar no protocolo.

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

Eve não pode saber se o Bob está simplesmente offline ou numa partição de rede diferente.

Blockchains como o Bitcoin, utilizando um consenso do tipo Nakamoto, favorecem a vida, o que significa que durante uma divisão de rede ambos os lados continuarão a produzir blocos e eventualmente rearranjarão se a partição for resolvida, enquanto outros, como cadeias Cosmos, usando um consenso do tipo PBFT, param sob partições de rede para preservar a consistência.

Regras de confirmação no Ethereum

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

Em condições de rede favoráveis, o Ethereum também visa fornecer garantias de consistência através da finalidade, usando o protocolo Casper FFG. A finalidade é a regra de confirmação mais forte possível, com os nós com uma regra codificada para nunca reorganização dos blocos finalizados.

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

As garantias de finalidade ficam comprometidas se dois blocos conflitantes forem finalizados, um evento que pode ocorrer se mais de 1/3 dos validadores agirem maliciosamente. No entanto, no Ethereum, tais ações vêm com a penalidade significativa de perder a sua participação.

Os utilizadores podem escolher se vão usar o Casper FFG como a regra de confirmação mais segura ou estar mais vivos confiando no LMD GHOST. As regras de confirmação para o LMD GHOST, à semelhança da regra de k-confirmação 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 Bloco Seguro.

Regras de confirmação sobre rollups

Os rollups podem, em princípio, usar as mesmas regras de confirmação disponíveis no Ethereum. Se enviar uma transação num conjunto e depois vir a mesma transação publicada em L1 num bloco finalizado, também pode querer considerar a transação L2 como final. Acontece que a história é muito mais complexa do que isso.

Rollups de dados de transações

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 conduzir ao estado que a raiz representa, todo o bloco é descartado, incluindo as transações que podem ser adicionadas posteriormente a outros blocos numa ordem diferente.

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

Rollup de diferenças de estado

As diferenças de estado são saídas de uma função de transição de estado e, para validar se são realmente válidas, é preciso esperar por uma prova ZK. A geração de prova ZK leva tempo e, além disso, há um incentivo para atrasar ainda mais para incluir mais transações numa única prova para amortizar melhor os custos de geração e verificação da prova.

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

Onde as coisas ficam complicadas

Especificações 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 numa ordem diferente em L1.

Para dar um exemplo, as cadeias OP Stack publicam lotes em L1 que são ligados usando os hashes do lote anterior. Estes lotes não precisam de ser publicados por ordem cronológica, o que leva a uma janela de sequenciação de 12 horas durante a qual os nós aguardam por transações potencialmente ausentes. As transações não devem ser consideradas incluídas apenas porque são publicadas em L1: se um lote ainda não estiver ligado à cadeia canónica de lotes, existe o risco de que seja construída uma bifurcação alternativa com uma ordem diferente ou conjunto de transações.

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 estão incluídas na primeira parte do primeiro bloco da época correspondente para o bloco L1 dado. Embora estas transações possam ser consideradas confirmadas sem esperar que a janela de sequenciamento passe, uma vez que a sua ordenação dentro do livro-razão L2 após a derivação é conhecida, é importante notar que os nós não começarão a calcular blocos contendo essas mensagens se faltar um lote anterior. Isto 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 o simples exame de dados na cadeia é insuficiente para rastrear os tempos de confirmação L1. Também é necessário perceber como os blocos L2 são derivados dos dados L1 examinando o próprio software do nó de rollup.

Funções permissidas

Scroll é um conjunto ZK que divulga dados de transação, o que significa que, em princípio, não é preciso esperar por uma prova ZK para considerar a transação final. Isso teria sido verdade se não implementassem uma função para apagar lotes que ainda não foram comprovados.

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

O mesmo pode aplicar-se aos rollups que publicam diferenças de estado: o ZKSync Era e o ZKSync Lite têm um processo de três etapas para postar diferenças de estado: primeiro, eles comprometem os dados sem qualquer prova, depois fornecem uma prova para eles e, depois de um atraso de 24 horas, a raiz fica disponível para ser executada para processar retiradas. Em teoria, quando é fornecida uma prova, a ordem das transações é fixa, por isso não é preciso esperar que o atraso de execução passe. Exceto, o ZKSync pode reverter esses blocos:

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

Embora para o ZKSync Era nenhum bloco tenha sido revertido, no ZKSync Lite aconteceu 8 vezes.

Observabilidade de finalidade

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

Vamos dar uma olhada em algumas das respostas:

Esta é uma solução que funciona se o sequenciador estiver disposto a responder-lhe e se confia nele. E se não acontecer? Ou, e se acontecer mas não confia nele? Como verifica se a alegação está correta?

A minha resposta favorita.

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

enquanto isso funciona, significa que a decisão técnica de usar diffs de estado vaza para a lógica da aplicação, o que significa que mesmo que um rollup seja equivalente a EVM, os projetos devem adaptar o seu contrato a essa consideração.

Uma solução parcial é postar uma raiz de transações e verificar a 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 respeitáveis, mas fica mais complicado numa configuração sem permissão.

Métricas de vida

Como primeiro passo para rastrear os tempos até a finalidade das transações de rollup, no L2BEAT começamos a rastrear as métricas de vida, em particular intervalos entre lotes de transações (se aplicável) e raízes estaduais. A lógica é que se um rollup for, por exemplo, interagir com L1 apenas uma vez por mês, os utilizadores não podem esperar que o tempo até a finalidade seja da ordem dos minutos. As métricas de vida podem ser pensadas como um indicador de limite inferior para o tempo até a finalidade: se um conjunto de dados de transação está a publicar lotes uma vez a cada dois minutos, e assumindo que a distribuição das transações L2 é uniforme, o tempo esperado para a finalização não é inferior a um minuto.

Aqui estão alguns exemplos de dados que estamos a rastrear para o ZKSync Era (atualizações de estado) e OP Mainnet (lote tx):

Métricas de vida ZKSync Era para o mês de setembro.

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

Como previsto, uma vez que as provas ZK demoram a ser geradas e há o incentivo para incluir mais transações numa única prova, o ZKSync Era tem métricas de vida piores do que o OP Mainnet. É importante ter em mente que, como discutimos nas secções anteriores, as métricas de vida não se traduzem diretamente em considerações de finalidade: no pior dos casos, o OP Mainnet tem realmente um tempo maior para finalizar por causa da sua janela de sequenciamento.

Agora pode explorar as métricas de vida para a maioria dos rollups no L2BEAT:

Limitações do rastreamento da vida

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

Um exemplo prático é o Starknet: embora observemos uma média de 32 segundos entre as atualizações do estado, o tempo até ao fim é realmente próximo de 6 horas:

Fonte: starkscan.co

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

Confirmações suaves

As confirmações suaves são regras de confirmação utilizadas para conseguir tempos de confirmação mais curtos no 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 txs diferentes no L1. Confirmações suaves incorretas são falhas atribuíveis, portanto, mecanismos para rastrear a reputação dos sequenciadores fora da cadeia ou corte na cadeia podem ser implementados. Em colaboração com a Nethermind, planeamos 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 asseguradas por um mecanismo de corte. Certo: valor total em risco de ser reorganizado ao longo do tempo.

Dando para a frente

Rastrear o tempo até ao fim é uma tarefa complexa. O nosso primeiro passo é monitorizar os intervalos de submissões de provas para os rollups ZK, que impõem um limite inferior superior no tempo até ao fim em comparação com os intervalos entre as submissões de raiz do estado. Depois disso, planeamos introduzir gráficos que exibem dados históricos de cada projeto. Posteriormente, a nossa investigação incidirá sobre todos os mecanismos adicionais que têm de ser considerados para, em última análise, atingir métricas em tempo real para o fim. Fiquem atentos!

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [medium]. Todos os direitos autorais pertencem ao autor original [Luca Donno]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.