20.000 palavras: O debate sobre segurança dos Rollups

Os rollups herdam a segurança?

Escrito originalmente por Jon Charbonneau

Originalmente compilado por Frank, Foresight News

Introdução

Goste-se ou odeie-o, o Twitter provavelmente nunca deixará de discutir se "L2" ou Rollup é "segurança herdada".

Embora a maioria dos debates sejam batalhas semânticas indiscerníveis, se você conseguir restringir o argumento, os pontos subjacentes são valiosos porque tocam nas questões centrais de quando, onde e por que o Rollup faz sentido.

O L2 escalável elimina a necessidade de L1 no mercado? É possível transformar um L1 como Solana em um L2?

Estes debates resumem-se principalmente a questões de segurança. Infelizmente, a definição de "segurança" aqui sempre foi muito evasiva. Geralmente usamos esse termo casualmente, e a maioria das pessoas sabe aproximadamente do que estamos falando, mas não completamente. Aqui vamos detalhar a segurança em detalhes em diferentes arquiteturas.

Definição de palavra da moda

Pacote cumulativo

Eu usei anteriormente a seguinte definição de Mustafa: "Rollup é um blockchain que publica seus blocos em outro blockchain e herda o consenso e a disponibilidade de dados (DA) desse blockchain".

A seguir está uma definição mais geral dada por James Prestwich: "Rollup é uma maneira de optar por outro mecanismo de consenso, personalizando funções de transição de estado e preservando o estado de superconjunto."

Nenhum dos dois requer uma ponte de verificação, e a capacidade de construir pontes entre cadeias com pressupostos de confiança mínimos é um grande benefício do Rollup, mas analisá-las separadamente é crucial.

Podemos considerar os seguintes critérios de rollup:

• Rollup é um sistema stateful (por exemplo, blockchain) derivado da execução de uma função de transição de estado personalizada (STF) na entrada de dados na cadeia principal (camada DA).
• Todos os dados de entrada (ou seja, dados completos da transação ou diferenças de estado) usados para derivar o estado de confirmação final da cadeia remota (ou seja, Rollup) são confirmados na cadeia principal.
• Como o estado Rollup é derivado da Função de Transição de Estado (STF) que é executada nos dados da cadeia principal, a validade do Rollup depende da validade da cadeia principal. O nó Rollup deve então verificar completamente o consenso e a validade da cadeia principal (ou fazer uma suposição majoritária honesta sobre a cadeia principal);

O nó Rollup determina o estado do Rollup no resultado de consenso da cadeia principal (como a cadeia principal confirmando a ordenação e a disponibilidade de blocos de dados) aplicando sua própria função de transição de estado (STF).

Ponte de cadeia cruzada

Uma ponte de cadeia cruzada é um sistema que permite que dois blockchains se comuniquem entre si. A cadeia A (a cadeia alvo) precisa ter certeza de que algo aconteceu na cadeia B (a cadeia de origem) e vice-versa. Idealmente, queremos que esta comunicação seja bidirecional, com atributos de segurança fortemente correlacionados (por exemplo, alta confiança de que a mensagem é válida, a cadeia de origem não será desfeita, etc.).

Fundamentalmente, a ponte de cadeia cruzada atua como um "observador" de outro blockchain (assim como qualquer outro usuário humano típico). A ponte cross-chain implementa uma determinada regra de confirmação pela qual está convencida do estado da cadeia conectada (por exemplo, quantos blocos Ethereum devem passar para aceitar entradas de transferência).

• As pontes tradicionais de cadeia cruzada normalmente executam nós leves de validação de consenso on-chain da cadeia de origem (ou seja, o que eles confiam na maioria dos sinais de consenso);
• As pontes de cadeia cruzada podem fornecer atributos de segurança mais fortes, agindo como nós leves de validação completa (ou seja, adicionando Amostragem de Disponibilidade de Dados (DAS) + Validade/Prova de Falha). Por exemplo, o validador de uma cadeia pode precisar ser executado em todos os nós leves do DAS que conectam a cadeia, o que é uma alternativa mais leve do que um nó completo que requer que o validador execute a cadeia conectada;
• Rollup cross-chain bridge também pode manter a atividade e resistência da cadeia principal (porque Rollup deve compartilhar o consenso da cadeia principal);

Ponte da cadeia principal → Rollup

Essa direção é muito simples, pois o nó Rollup verifica totalmente a cadeia principal.

Os nós de rollup sabem tudo o que acontece na cadeia principal, então eles sabem quando as transações em ponte de cadeia cruzada ocorrem, e o nó completo atual do Ethereum Rollup também deve executar o nó completo para a própria camada base do Ethereum.

Observe que os nós de rollup também podem executar um nó leve validador completo de sua cadeia principal, se suportado. Vamos considerar um exemplo hipotético onde o Ethereum implementou totalmente as seguintes atualizações:

• Blocos de execução Ethereum com prova de validade (a pesquisa zkEVM na camada base está em andamento);
• Ethereum implementou um DAS completo, para que os nós possam experimentar o DA;
• A camada de execução Ethereum publica seus dados como blobs para a camada de dados, assim como qualquer outro rollup no Ethereum (por exemplo, os dados da camada de execução da Celestia serão publicados em sua camada DA, então os nós DAS verificarão a disponibilidade dos dados do Rollup e da própria camada de execução da Celestia);
• Ethereum fornece prova completa de consenso em vez de depender de comitês de sincronização (por exemplo, através da integração de validadores, melhor agregação de assinaturas, possível prova de consenso ZK, etc.);

Agora, supondo que você queira executar um nó completo para um rollup baseado em Ethereum, para seguir uma cadeia de rollup válida, você deve entender a cadeia canônica do Ethereum, que requer verificar o consenso e a validade do próprio Ethereum:

• Consenso Ethereum - qualquer cliente de nó leve pode rastrear o consenso assinado como o blockchain, cabeçalho do bloco;
• Camada de execução própria do Ethereum DA – Os nós de rollup amostram a camada DA do Ethereum, verificando a disponibilidade dos dados do Rollup e os dados da própria camada de execução do Ethereum (note que os nós DAS ainda fazem algumas suposições adicionais sobre nós completos, como veremos mais adiante);
• Validade de estado próprio do Ethereum – com zkEVM, cada bloco Ethereum vem com uma prova de validade;

Os nós de rollup devem verificar a validade de estado e DA da própria camada de execução do Ethereum, pois estas são as condições de validade para blocos Ethereum. O nó Rollup precisa saber que ele não apenas rastreia Ethereum onde o consenso foi assinado, mas também que é um cabeçalho de bloco válido. Por exemplo, eles podem rastrear acidentalmente blocos Ethereum que são assinados por consenso, mas inválidos (por exemplo, gera muito ETH).

Se a própria camada de execução subjacente publicar seus dados na camada DA (assim como outros rollups) e adicionar validade ou prova de falha, ela se tornará um pacote cumulativo interno.

Ponte do Rollup → cadeia principal

Essa direção é complicada, porque a cadeia principal não conhece o estado do Rollup e STF por padrão (ou seja, os nós Ethereum não precisam executar nós Rollup). Para que a cadeia principal acredite no estado do rollup, você pode implementar a lógica do rollup no contrato inteligente implantado na cadeia principal (ou seja, o contrato de ponte de verificação do rollup). Este contrato inteligente verifica a validade dos estados DA e Rollup.

Mais uma vez, esta ponte de cadeia cruzada é opcional. Os contratos inteligentes na cadeia principal são usados para convencer todos os nós principais da cadeia da validade do Rollup, que permite a comunicação bidirecional sob pressupostos de boa confiança.

Rollups, Coprocessadores e Intenções

Como discutido, os Rollups salvam parte de seu próprio estado (estado do Rollup), além de possuir o estado de sua cadeia principal (por exemplo, Ethereum). Então, o CoW Swap tem seu próprio estado que não faz parte do estado Ethereum? Se sim, então soa como um rollup. Se não, então pode ser um "coprocessador".

No entanto, mesmo esta questão não é tão simples como parece:

Em vez disso, você pode pensar que o fator distintivo é a persistência do estado:

Se o CoW Swap permite que participantes específicos forneçam aos usuários pré-confirmações rápidas (mais rápidas do que o tempo de bloqueio do Ethereum) e promete ordens que incluem lotes - já que o processamento em lote do Ethereum leva mais tempo do que a maioria dos usuários gostaria, agora é um rollup?

Chris Goes abordou este tema em sua palestra no Modularity Summit, começando com uma definição aproximada de intenções: "o compromisso de uma função de preferência para um determinado espaço de estado do sistema".

Observe as semelhanças entre a resolução parcial (intenção de correspondência) e a classificação cumulativa. O operador obtém a mensagem assinada off-chain do usuário → publica os dados resultantes na cadeia principal.

• Aplicações baseadas em intenção – as alterações de estado resultantes são resolvidas on-chain (por exemplo, no exemplo CoW Swap, a aplicação está na cadeia subjacente, então os tokens são trocados lá);
• Aplicação Rollup – utiliza os dados submetidos à cadeia principal para calcular as alterações de estado geradas pelo Rollup;

As arquiteturas centradas na intenção e as arquiteturas centradas no rollup atingem objetivos semelhantes em direções opostas. A abordagem centrada na intenção aborda esse problema amplamente da perspetiva de usuários e aplicativos, e a abordagem centrada no Rollup aborda esse problema amplamente da perspetiva de diferentes blockchains.

Aqui, não é importante estabelecer limites distintivos específicos. Além disso, descobrimos que o Rollup não é muito diferente dos aplicativos aos quais nos acostumamos com a correspondência de intenção off-chain!

Você confia em participantes off-chain (sequenciadores vs. solucionadores/preenchedores, etc.) para obter algumas garantias mais fracas, como fornecer a melhor execução e uma boa experiência do usuário → determinar o resultado com base nos dados publicados na cadeia principal. No entanto, eles não mantêm seus fundos sob custódia.

À medida que a computação off-chain verificável se torna mais importante, as linhas entre os dois podem tornar-se esbatidas:

Se você quiser que o solucionador de intenções ou o pedido de rollup sejam menos confiáveis...

Blockchain modular e blockchain monolítico

Blockchains monolíticos (também conhecidos como blockchains integrados) são frequentemente definidos como cadeias que integram verticalmente todas as funções principais, ou seja, consenso, DA, e execução. Eles assumem total responsabilidade por sua própria segurança, e Solana e Cosmos Hub são excelentes exemplos.

As camadas DA (como Ethereum e Celestia) são muitas vezes referidas como blockchains "modulares" porque terceirizam a execução para o Rollup, mas isso não é totalmente preciso. São também responsáveis de forma independente pelo seu próprio consenso, DA, e aplicação.

Mesmo a execução de Celestia será limitada (por exemplo, transferências, staking, cross-chain). Da mesma forma, se alguém iniciar o Rollup em cima do Solana, ele não se tornará magicamente um blockchain "modular".

Então, quando você ouvir as pessoas se referirem a cadeias como Ethereum ou Celestia como blockchains "modulares", perceba que esta é mais uma distinção prática do que estritamente técnica. Ambos geralmente otimizam suas próprias arquiteturas para oferecer suporte ao Rollup. Espera-se que esses rollups lidem com a maior parte da execução de negociação dentro de seu escopo.

Mesmo o Rollup não é necessariamente completamente "modular" — o sequenciador do Rollup pode concordar com o sequenciamento de transações, fornecer DA, e executar transações antes que a cadeia principal faça qualquer coisa. É assim que os usuários são pré-confirmados. A cadeia principal então fornece outro compromisso "final", declarando novamente o DA e o consenso sobre a ordem das transações do Rollup.

Rollups e Cadeias Integradas

Para os nossos propósitos, a distinção mais importante é "Rollup" ou "Non-Rollup". O estado final da cadeia tem origem em dados publicados numa cadeia principal separada (ou seja, camada DA)?

Embora hoje associemos DAS e validade/prova de falha com rollups tradicionais, devemos notar que estes são conceitos logicamente diferentes. Em teoria, qualquer "cadeia de integração" (como uma cadeia de aplicativos Cosmos típica) pode ser atualizada para adicionar DAS e provas de validade sem ter que publicar seus dados em outras mainchains externas, como o Ethereum. O nó fará uma amostragem e verificará a cadeia separadamente.

Vitalik fala sobre essa diferença em seu Ultimato:

Você pode notar que um "blockchain grande tradicional" (cadeia de integração) com validade DAS + / prova de falha pode acabar parecendo um "rollup consagrado"! Da mesma forma, "um rollup escalável e dominante" pode se tornar tão bem-sucedido que simplesmente se funde com sua cadeia principal para acomodar esse rollup.

As fronteiras da distinção tornam-se esbatidas no limite.

Portanto, se você acredita que a eficácia/prova de falha do DAS+ é o resultado final, então "Rollup", em certo sentido, é inevitável. Há uma diferença válida entre os dois métodos no diagrama anterior:

• "Rollups" também conhecido como "modularidade" - construir cadeias logicamente independentes, publicar dados em sua cadeia principal (camada DA) e reutilizar o consenso da cadeia principal;
• "Integrated blockchain" também conhecido como "blockchain monolítico" - integrar tudo em um protocolo com seu próprio consenso, sem publicar dados em uma cadeia principal separada (mesmo que a camada DA e a camada de execução sejam partes logicamente separadas do protocolo compartilhado em certo sentido);

Quando falamos de "Rollup" neste relatório, estamos nos referindo ao primeiro (ou seja, não uma cadeia de integração com validade DAS + / prova de falha, que pode ser referida como built-in Rollup).

Embora o Rollup "tradicional" não tenha o monopólio do DAS ou provas (ou seja, grandes blockchains integrados podem adicioná-los), observe que estamos ignorando muitos detalhes técnicos aqui, e você não pode simplesmente escolher Solana e decidir "Oh, acho que vamos adicionar DAS hoje".

Isso requer uma refatoração fundamental do protocolo para começar a se aproximar do que estamos vendo Ethereum e Celestia fazendo:

Alterar a forma como os dados são codificados para suportar DAS equivalerá a abrandar a codificação e propagação de blocos, começando a aproximar-se da camada DA tradicional:

Por esse motivo, vemos a equipe construir o seguinte:

• Camadas DA especializadas (por exemplo, Danksharding do Ethereum, Celestia, etc.) - blocos lentos + DAS;
• Sequenciadores compartilhados (por exemplo, Espresso, Astria ou mesmo Solana) - realmente apenas camadas DA rápidas, sem necessidade de DAS;

No entanto, se você separar o tempo de blocos rápidos e DAS, eles não são necessariamente compatíveis. Por exemplo, você pode imaginar uma cadeia como Solana oferecendo dois caminhos diferentes:

• Caminho rápido - continuar a executar transações e disseminar dados o mais rápido possível (como é hoje);
• Caminho lento - codificar dados após o fato de forma que a amostragem assíncrona possa ser realizada, fornecendo a garantia de que os nós DAS estão ligeiramente atrás do consenso;

Anatoly discute no podcast como o Eclipse une Ethereum, Celestia e Solana e, do outro lado do espectro, você pode imaginar a camada DA adicionando um caminho mais rápido antes de disponibilizar os dados para amostragem:

Fornecer dois caminhos no mesmo protocolo de camada base internaliza efetivamente a classificação compartilhada rápida, fornecendo um design interessante baseado no Rollup. Note-se que, de momento, esta é ainda uma ideia muito exploratória.

Confirme a regra

Com esse pano de fundo, podemos agora começar a decompor os atributos de segurança dessas diferentes arquiteturas.

Primeiro, os nós interagem com qualquer blockchain executando "regras de confirmação":

"As regras de confirmação referem-se ao algoritmo que é executado por um nó para produzir se um bloco é confirmado ou não. Neste caso, sob certas premissas, envolvendo principalmente a sincronização da rede e o percentual de ações honestas, quando essas condições forem cumpridas, o bloqueio será garantido que uma reorganização nunca ocorrerá".

Pode haver qualquer número de regras de confirmação para uma determinada cadeia:

• Quantos blocos você precisa esperar antes de confirmar uma transação Bitcoin? 1 ？ 6 ？ 10 ？
• Você usa LMD GHOST para confirmar blocos com base no livro-razão utilizável Ethereum, ou você espera que o gadget final (Casper FFG) confirme?
• Você executa nós completos que verificam diretamente cada bloco, ou apenas nós leves que verificam a assinatura de consenso?
• Você acabou de perguntar Infura?

Como cada regra de reconhecimento pode fazer suposições muito diferentes, elas podem ter propriedades de segurança muito diferentes, mesmo quando interagem com a mesma cadeia:

Esta distinção é subtil, mas importante:

Segurança = Segurança + Atividade

Agora vamos analisar se o Rollup "herda a segurança" de sua cadeia principal.

Herança, e talvez mais claramente, Rollup sempre "aluga" em vez de "herdar" qualquer coisa em sua cadeia principal, paga um custo contínuo pelos recursos consumidos (DA), e qualquer uma das partes pode optar por terminar o relacionamento. Mas essa não é a parte interessante do problema.

Segurança, a partir de agora vamos nos concentrar na segurança. A segurança de um algoritmo consiste em Segurança e Vivacidade:

• Segurança (nada de ruim acontecerá), o estado final determinado por dois nós saudáveis nunca entrará em conflito;
• Liveness (coisas boas acontecerão eventualmente), todos os nós saudáveis completarão um novo estado refletindo as transações incluídas dentro de um tempo limitado;

Usando a excelente estrutura do Sreeram, podemos dividi-los em cinco atributos que trabalham juntos para garantir as regras de confirmação:

Vamos considerar um exemplo de uma hipotética cadeia de integração com DAS + validade/prova de falha. Os seus dados não são publicados em nenhuma outra cadeia principal externa. Para simplificar, assumimos a finalização instantânea (por exemplo, Tendermint), portanto, não há distinção utilizável entre um livro-razão disponível e um livro-razão finalizado (por exemplo, o Gasper do Ethereum).

Vamos considerar três regras de confirmação que podem ser usadas para rastrear a cadeia usando diferentes tipos de nós:

• Nó leve do validador de consenso - verifica a prova de consenso (ou seja, confia no consenso da maioria honesta).
• Nó de luz validador completo - verificar consenso + verificar DA (usando DAS) + verificar validade do estado (usando validade / prova de falha);
• Nó completo - consenso de verificação + verificação direta de DA (download de todos os dados) e validade (execução de todas as transações e cálculo de status);

Confirme se a regra tem atributos de segurança, a cadeia não

Mais uma vez, "falamos coloquialmente que uma cadeia é segura, mas na verdade é uma regra de confirmação anexada ao atributo de segurança".

Vejamos alguns exemplos.

Teorema da PAC

Como pano de fundo, o teorema da PAC diz-nos que nenhum livro razão pode satisfazer ambas as condições ao mesmo tempo:

Adaptabilidade (também conhecida como disponibilidade dinâmica) - manter-se ativo com participação dinâmica (ou seja, se a maioria dos nós estiver offline); Finalidade (também conhecida como consistência) – manter a segurança sob partições de rede;

Os protocolos de consenso tendem a ser divididos em duas partes, cada uma das quais satisfaz uma das condições acima:

• Protocolos de cadeia mais longa - estes protocolos (por exemplo, o Consenso Satoshi do Bitcoin) garantem a atividade mesmo quando o número de nós participantes ativos é variável (ou seja, eles são adaptativos), no entanto, eles não são seguros (ou seja, não são finais) sob particionamento de rede; Protocolos do tipo BFT - Os protocolos de consenso clássicos (por exemplo, PBFT) atingem a finalidade, mas não alcançam a adaptabilidade;

Regras de confirmação do Bitcoin

O consenso do Bitcoin não fornece nenhuma finalidade econômica difícil.

Os nós observam a cadeia mais longa em sua visualização local, e cada usuário é livre para aplicar qualquer regra de confirmação que quiser (por exemplo, aceitar blocos com confirmações >k). O padrão é esperar que 6 blocos sejam confirmados, mas depende de você.

Para transações de maior valor, é razoável esperar mais tempo. Existe um trade-off entre tempo de espera e segurança, ou seja, a possibilidade de reorganização.

Regras de confirmação do Ethereum

O consenso PoS do Ethereum (Gasper) parece, à primeira vista, contornar o teorema da PAC. No entanto, ele implementa essas duas propriedades porque contém dois livros aninhados:

• Livro-razão dinamicamente disponível - se a rede não é particionada, é seguro e ativo com participação dinâmica;
• Livro-razão de prefixos finalizado - sempre seguro e protegido. Se a rede não for particionada e houver nós suficientes, ela permanecerá ativa;

Gasper pertence à família de protocolos "ebb-and-flow" (também conhecido como double ledger ou regra de confirmação dupla). O desenho de dois livros não se enquadra no âmbito do teorema da PAC (ou seja, pressupõe uma única regra de confirmação). Quando a rede é particionada, o livro-razão finalizado fica atrás do livro-razão adaptável, mas alcança quando a rede é reparada.

Isto permite que o compromisso entre adaptabilidade e finalidade seja abordado ao nível do utilizador e não a nível de todo o sistema. Esta é uma característica do protocolo de "cadeia mais longa de pontos de verificação" proposto pelo teorema CAP blockchain em termos de adaptabilidade e finalidade em que os usuários podem confiar. Estes protocolos proporcionam aos utilizadores individuais uma escolha entre finalidade e adaptabilidade, em vez de a imporem ao nível global do sistema.

Gasper expõe explicitamente duas regras de confirmação diferentes, mapeadas para os dois livros contábeis mencionados acima:

• Regras dinamicamente disponíveis - adaptabilidade garantida. Respeite o cabeçalho do bloco da cadeia mais longa. LMD GHOST é uma regra de seleção de bifurcação usada para determinar a subárvore mais pesada;
• Regras de Finalização - Garante a certeza final. Respeite os bloqueios confirmados pelos gadgets finais. Os FFGs Casper são gadgets finais que se aplicam em cima das regras de seleção de garfo;

Conforme discutido no artigo:

"Regras adaptativas mais otimistas sempre confirmam blocos marcados como finalizados por regras mais conservadoras, e podem confirmar mais blocos durante níveis variáveis de participação. Os clientes (usuários) escolhem localmente entre as regras de confirmação com base nas preferências pessoais, enquanto os mineradores seguem regras de proposta de bloco fixo que são consistentes com essas duas regras de confirmação".

Isso permite que todos os nós (honestos) no sistema:

• Seguir um mecanismo comum de proposta de bloco;
• No entanto, diferentes nós podem escolher diferentes regras de confirmação;

Os validadores continuam a alongar a cadeia mais longa (minerando novos blocos em alturas cada vez maiores), independentemente do nível de participação, mas apenas quando houver participação suficiente, novos pontos de verificação aparecerão.

A cadeia mais longa (contendo o ponto de verificação mais recente) pode alternar entre diferentes cadeias (ou seja, remontar blocos incompletos), mas é garantido que o ponto de verificação esteja em uma única cadeia, independentemente das condições da rede (ou seja, finalidade).

A segurança dos utilizadores depende das regras de confirmação que seguem. Existe um compromisso entre o reconhecimento rápido do bloco e garantias de segurança mais fortes. Os usuários que vendem café podem preferir a atividade à segurança, mas os usuários que vendem iates podem preferir a segurança à atividade.

Os nós Ethereum também podem aplicar algumas outras heurísticas de regras de confirmação intermediárias para fins práticos. Em vez de usar blocos k ingênuos como uma regra de confirmação adaptativa, como o Bitcoin faz, podemos adicionar outras heurísticas que incluem suposições sobre sincronização de rede e honestidade do validador.

Isto é exatamente o que é proposto nas Regras de Confirmação do Protocolo de Consenso Ethereum, que propõem regras de confirmação com as seguintes propriedades:

• Em condições ideais - a regra confirmará um novo bloco imediatamente após o seu slot;
• Em condições típicas de mainnet - a regra deve ser capaz de confirmar a maioria dos novos blocos dentro de um minuto;

Esta regra de confirmação não substitui a finalidade económica. Em vez disso, ele fornece heurísticas úteis para usuários que acreditam que a sincronização de rede permanecerá no futuro próximo. Vamos comparar os dois:

Vamos considerar alguns exemplos, como se você vender um iate por US $ 2,5 milhões em ETH, aqui estão algumas regras de confirmação possíveis:

• Nó completo + esperando pelo resultado final – mesmo uma maioria maliciosa de validadores não pode enganá-lo para aceitar blocos inválidos (por exemplo, produzindo ETH falso). Se eles pagarem US$ 2,5 milhões em ETH e depois tentarem reestruturar o bloco finalizado mais tarde, incorrerão em um custo enorme (pelo menos um terço do patrimônio é cortado com pudição);
• Nó completo + esperar por um bloco - a maioria dos validadores maliciosos ainda não pode enganá-lo para aceitar um bloco inválido, no entanto, eles podem enviar-lhe US $ 2,5 milhões em ETH em um bloco válido, deixar em um iate e, em seguida, o bloco é imediatamente reorganizado, o que é possível se houver peso de estaca suficiente ou más condições de rede, eles não são cortados punitivamente;
• Light Node Client – Placas de sincronização maliciosas podem mentir para você sem penalidade e os compradores podem deixar no iate (note que este comitê de sincronização é exclusivo do Ethereum como um subconjunto de consenso, outras cadeias PoS com suporte ao cliente de nó leve mais eficiente podem verificar todos os votos de consenso com um pequeno número de validadores);
• MetaMask – Você só confia em Infura, a pessoa que comprou o iate de você prometeu ao funcionário da Infura que eles poderiam levar o iate no fim de semana, então eles mentiram para você, você pensou que tinha recebido US $ 2,5 milhões em ETH, e então você entregou as chaves;

Rollup confirma as regras

Como em qualquer cadeia, os nós interagem com o Rollup usando diferentes regras de reconhecimento. As regras de confirmação mais fortes do Rollup serão finalizadas juntamente com o consenso de sua cadeia principal. O sequenciador Rollup pode expor regras de confirmação mais fracas para uma melhor experiência do usuário (ou seja, fornecer pré-confirmação rápida para usuários impacientes), mas os usuários também podem esperar pela segurança total das regras de confirmação da cadeia principal.

Um fluxo de transação típico do Rollup tem esta aparência:

• O usuário envia uma transação para o sequenciador;
• O sequenciador classifica as transações e dá pré-confirmação;
• STF determinístico deve ser aplicado a transações ordenadas para calcular o novo estado de rollup;
• O compromisso de status de rollup atualizado e os dados de transação relacionados são finalmente liberados para a cadeia principal;

Depois que os dados da transação são publicados na cadeia principal:

• Rollup Full Node - verifica diretamente se o estado da cadeia proposto está correto;
• Nós leves de rollup (incluindo pontes de verificação) - não podem ser verificados diretamente;
• Observadores diferentes do mesmo Rollup usam regras de confirmação diferentes, para que finalizem seu ponto de vista em momentos diferentes:
• Assumir a liberação de dados completos da transação (não apenas diferenças de estado);
• Como mencionado anteriormente, os nós de rollup também devem executar nós completos da cadeia principal ou nós leves do validador completo (ou usar nós leves do validador de consenso para fazer suposições de maioria honesta). Os nós leves de rollup podem ser executados como software adicional ou implicitamente dentro do nó da cadeia principal (ou seja, rollup de verificação de contrato de ponte de cadeia cruzada na cadeia principal);

Os usuários também podem confirmar transações mais rapidamente, confiando no sequenciador para confirmar com antecedência, mesmo antes do link principal receber os dados. Se o sequenciador se comportar incorretamente, a segurança pode falhar. Então, uma vez que os dados estejam na cadeia principal (e você tenha verificado a validade do DA+), apenas uma falha na cadeia principal (como uma reorganização do Ethereum) afetará sua segurança.

Portanto, mesmo os ordenadores centralizados não reduzem realmente a segurança do "Rollup". Você sempre obtém segurança que está em conformidade com as regras de confirmação que você precisa. Se o Rollup tem um design baseado em sequenciador ou outro, você pode usar as mesmas regras de confirmação (por exemplo, esperar que a cadeia principal seja finalizada e verificar a validade do Rollup). Supondo uma implementação adequada (por exemplo, impondo a inclusão de transações através da cadeia principal), você pode obter os mesmos atributos de segurança dentro do mesmo período de tempo, mantendo outras condições iguais.

Da mesma forma, você pode imaginar que os produtores de blocos Ethereum L1 fornecem pré-confirmação devido a tempos de bloqueio lentos, o que não torna o "Ethereum" menos seguro. Você só precisa decidir se deseja usar outra regra de confirmação (menos segura) até que o validador Ethereum finalize a segurança mais alta.

A ideia de pré-confirmação se encaixa bem com a lógica de Gasper descrita por Vitalik:

O princípio geral é que você quer fornecer "o máximo de consenso possível" para o usuário: se houver > 2/3, então chegamos a um consenso regularmente, mas se houver < 2/3, então não há razão para atrasar sem fornecer nada, porque obviamente a cadeia continuará a crescer apesar do nível de segurança temporariamente mais baixo do novo bloco. Se um único aplicativo não estiver satisfeito com um nível inferior de segurança, sinta-se à vontade para ignorar esses blocos até que eles sejam finalizados.

Juntando tudo isso, quando todas as regras de confirmação concordam com o mesmo estado do livro-razão ao mesmo tempo, temos uma "área de consistência":

Confirme a regra - segurança e acessibilidade

Se sua regra de confirmação é confiar em um único sequenciador executado por um SBF, em vez de um sequenciador descentralizado composto pelos validadores mais respeitáveis do mundo, então sua segurança pode ser pior, e a falha ativa e a reorganização são falhas de segurança.

Como alternativa, você pode esperar que regras de confirmação mais fortes (mainchain) fiquem disponíveis. Então, sendo tudo igual, um sequenciador não confiável não afetará sua segurança. Se você está vendendo café, você provavelmente vai imediatamente, mas se você está vendendo um iate, você precisará verificar novamente a confirmação da cadeia principal.

No entanto, se todos realmente usam essa regra de confirmação para vender seu iate, não podemos ignorar completamente a segurança potencialmente baixa da regra de confirmação "confiar em pessoa aleatória executando um sequenciador separado". O design preciso é baseado em um equilíbrio do nível de comprometimento progressivo necessário para o tempo para um determinado caso de uso.

Mais uma vez, isso toca em críticas reais a blockchains de alto rendimento como Solana. Que regras de confirmação as pessoas podem realmente usar? Você pode ter boas condições de segurança para executar nós completos do Solana, mas a maioria das pessoas pode não ter acesso a essa regra de confirmação (ou seja, dependendo dos requisitos de recursos e/ou custo).

A verificação direta (ou seja, não apenas confiar na maioria honesta) é um atributo central desses sistemas. Então, para uma determinada regra de confirmação, nós realmente nos preocupamos com dois aspetos – segurança e acessibilidade:

Numa palavra:

• Os usuários interagem com qualquer cadeia através de regras de confirmação;
• Uma cadeia pode ter qualquer número de regras de confirmação;
• A segurança é um atributo da regra de confirmação, não da cadeia em si;
• Preocupamo-nos com a segurança e acessibilidade das regras de confirmação para uma determinada cadeia;

De facto, quando dizemos que uma dada cadeia é segura, estamos a tentar expressar a noção de que as regras de confirmação associadas são seguras e acessíveis.

Rollups com segurança da cadeia de integração

1 , cadeia de integração com prova de validade do DAS+

Estamos vendo agora que a segurança em relação à validade de DA e estado pode ser verificada diretamente por criptografia (DAS + validade / prova de falha) sem fazer suposições fortes sobre os operadores da cadeia. Qualquer protocolo pode implementá-los tecnicamente. Os nós completos também podem verificar a validade do DA e do estado sem suposições externas.

Agora vamos nos concentrar em outras propriedades - atividade e resistência à recombinação. Como vimos anteriormente, eles podem falhar, independentemente do tipo de regra de confirmação executada. Vejamos outra cadeia de integração que comprova a finalidade da eficácia DAS+ do soquete único +PoS:

A escolha de regras de reconhecimento fortes é particularmente eficaz para um subconjunto de falhas de segurança, onde até mesmo a maioria dos validadores mal-intencionados não consegue enganar nós completos ou nós leves de validador completos para acreditar que:

• Dados não disponíveis estão realmente disponíveis;
• ou transições de estado inválidas são válidas;

Quer o Ethereum tenha 1 validador ou inúmeros validadores, todos os nós acreditam mais ou menos no DA ou na validade do bloco, que são garantidos pela verificação. Os nós de luz do validador completo podem ser verificados de uma maneira mais simples (mas observe que o DAS faz algumas outras suposições, que discutiremos mais adiante).

No entanto, uma maioria mal-intencionada de validadores pode impedir que o livro razão cresça, censurando você ou reorganizando a cadeia (quais falhas ocorrem depende das regras de confirmação). DAS + ZK não vai salvá-lo. A resistência à reorganização e à atividade depende sempre, em certa medida, dos vários atributos subjacentes a uma dada cadeia (por exemplo, operadores fiáveis, incentivos económicos, consenso social, etc.).

Menos obviamente, atividade e resistência à reorganização ainda são atributos de uma determinada regra de reconhecimento, uma vez que cada nó está sujeito ao mesmo ataque que na tabela acima. Independentemente das regras de confirmação aqui, eles têm a mesma garantia.

No entanto, isso se torna aparente novamente quando você remove a suposição de finalidade de slot único. No Gasper do Ethereum, dependendo do livro-razão que você seguir (ou seja, o livro-razão de cadeia ou ponto de verificação mais longo disponível), você terá novamente diferentes propriedades resistentes à atividade e à reorganização. A maioria dos validadores mal-intencionados causa falhas de segurança diferentes, dependendo das regras de confirmação executadas.

De qualquer forma, a questão é que a construção subjacente da cadeia é muito importante aqui. São necessários operadores fortes, incentivos económicos e consenso social para manter a cadeia ativa e resistente à reestruturação. Além disso, protocolos de consenso de livro-razão duplo, como o Ethereum, fornecem aos usuários uma flexibilidade valiosa para calcular a disponibilidade e a finalidade de acordo com suas necessidades.

2, Prova de Rollup usando DAS + validade

Agora vamos modificar um pouco este exemplo:

• Exemplo anterior - uma cadeia de integração com prova de validade de DAS+, imagine tomar o Solana de hoje, mas adicionando prova de DAS+;
• Novo exemplo - O Rollup é implantado em uma cadeia principal externa (por exemplo, Ethereum) com prova de validade + DAS (note que o Ethereum DAS ainda não está ativo), o Rollup tem um conjunto de sequenciadores descentralizados que podem chegar a um consenso com pré-confirmação rápida;

Você notará que o Rollup tem dois tipos completamente separados de regras de confirmação para períodos de tempo diferentes (ou seja, se você está operando com base no pré-consenso do sequenciador ou aguardando o consenso final da cadeia principal), vamos agora olhar para cada caminho.

Fast Path - Antes do consenso da cadeia principal

Os nós de rollup podem contar com a confirmação do sequenciador (antes de publicar na cadeia principal), e assumimos que eles podem executar os seguintes nós de rollup:

• Rollup Consensus Validator Light Node - Confie na maioria honesta no consenso do sequenciador Rollup;
• Rollup Full Validator Light Node - executa DAS + no feed do sequenciador para verificar a prova de validade antes de publicar qualquer coisa no Ethereum;
• Rollup Full Node - Baixe todos os dados do feed do sequenciador e execute todas as transações para verificar diretamente o DA e a validade;

Tecnicamente, o sequenciador Rollup pode facilitar o DAS e fornecer prova de validade antes de publicar na cadeia principal, mas isso não acontece de fato. Os nós de luz do validador completo geralmente são projetados para verificá-los através da cadeia principal, mas estou supondo que as provas DAS+ "ao vivo" podem ser comparadas mais claramente com o mesmo que a cadeia integrada.

A tabela a seguir mostra as alterações em comparação com o exemplo de cadeia de integração:

• Confie no sequenciador Rollup para atividade e anti-recombinação, em vez do conjunto validador da cadeia integrada;
• Apenas removido o atributo de atividade final, porque apenas o intervalo de tempo antes do consenso da cadeia principal é visto aqui (esses atributos de atividade "final" serão de propriedade própria mais tarde no futuro);

As exclusões são mostradas com um tachado vermelho e as adições são mostradas em azul:

Caminho lento - Aguarde o consenso da cadeia principal

Para segurança extra, os nós podem esperar pelo consenso da cadeia principal (por exemplo, Ethereum), que é onde ele entra em jogo mais claramente, ou seja, os nós de rollup também devem executar o nó da cadeia principal:

• Nó leve do validador de consenso da cadeia principal - confie no consenso da maioria honesta da cadeia principal;
• Nó leve do validador completo da cadeia principal - verifique a prova de validade da cadeia principal + execute DAS na cadeia principal (incluindo dados Rollup + dados da cadeia principal);
• Mainchain full node - baixar todos os dados da mainchain (incluindo verificação de dados rollup) + executar todas as transações mainchain para verificar diretamente a validade;
• Observe que a validade do estado do Rollup pode ser verificada através de dois caminhos diferentes:
• Fora da cadeia principal (executando software adicional do nó Rollup) - O Rollup não requer que sua cadeia principal verifique seu estado ou STF, não precisa implantar uma ponte de verificação, em vez disso, pode verificar a prova do Rollup por outro método (por exemplo, recebendo a prova do Rollup via p2p), o que requer a execução de software adicional do nó Rollup para verificar a prova (ou seja, nós leves do Rollup);
• Dentro da cadeia principal (implementar o nó Rollup dentro da cadeia principal) - esta é a norma hoje, a lógica do validador do nó leve do Rollup é implantada na própria cadeia principal (ou seja, o contrato de ponte embutido do Rollup), uma vez que este nó validador do Rollup é executado dentro do STF da cadeia principal, validar o STF da cadeia principal também significa verificar o STF do rollup;

Se obtivermos uma cadeia principal à prova de conhecimento zero (por exemplo, Ethereum L1 zkEVM) + todos os rollups provarem seu estado dentro da cadeia principal→ obteremos a visão de Vitalik de prova de singularidade. Uma prova de conhecimento zero de validação do Ethereum significa validar todas as outras cadeias e validar nós de suas implementações internas:

Para simplificar, assumimos aqui que a validade de estado do rollup é verificada dentro da própria cadeia principal (por exemplo, o rollup tem uma ponte incorporada com a cadeia principal), pelo que podemos ignorar explicitamente a execução de software adicional do nó rollup fora do protocolo.

As alterações em relação à tabela anterior do Fast Path Rollup são as seguintes:

Isso é conseguido pela mainchain forçando as transações a incluir ou impondo a substituição de sequenciador/provador, que chamamos de atividade "final" aqui, porque do ponto de vista do Rollup, é um caminho lento, mas do ponto de vista da cadeia principal, isso pode ser considerado atividade "em tempo real".

Rollup com blockchain integrado

Agora podemos ver as mudanças nos atributos de segurança relacionados ao blockchain integrado e ao Rollup:

• DA e validade do estado - Se implementada, a prova de validade DAS+ pode fornecer garantias de segurança aplicáveis, independentemente de a cadeia ser integrada ou Rollup tradicional. Na verdade, essas tecnologias hoje são dominadas pelo Rollup; Liveness & Re-org Resistance - As blockchains integradas são responsáveis por isso de forma independente em todos os cenários. Em vez disso, o Rollup oferece uma escolha de regras de confirmação dentro de diferentes períodos de tempo. Você pode usar regras de confirmação menos seguras (consenso do sequenciador de confiança) para obter garantias rápidas, ou esperar por regras de confirmação mais seguras (esperar pelo consenso da cadeia principal);

Atividade e resistência à recombinação

Esses atributos não podem ser garantidos com uma senha e, mesmo entre as regras de confirmação (por exemplo, se estiver executando um nó completo ou leve), você pode estar vulnerável a falhas de segurança.

Se o operador estiver completamente fora de controle, nenhum nó completo ou prova ZK poderá protegê-lo de falhas de atividade ou reorganização.

Estes atributos são alcançados através de operadores fortes e descentralizados, mecanismos resistentes à censura, consensos propícios à atividade, elevado "custo" de reestruturação, forte consenso social, etc. Compará-los objetivamente é muitas vezes um desafio.

Como se mede a descentralização dos operadores e o consenso social? Não há uma resposta certa. Estes são, sem dúvida, os aspetos mais difíceis de conceber, e são, de facto, muito exclusivos de uma dada cadeia.

É importante ressaltar que vemos que o Rollup pode delegar anti-reorganização e atividade à cadeia principal e que as regras de confirmação usadas no Rollup podem ter os mesmos atributos de segurança como se estivessem sendo executadas na cadeia principal dentro do mesmo período de tempo.

As cadeias podem até escolher quais atributos delegar a qual cadeia, e diferentes tipos de arquiteturas "L2" (como validiums, otimismo e sidechains) podem absorver diferentes subconjuntos de atributos de segurança. Por exemplo:

• Anti-reestruturação - O Rollup pode delegar a anti-reestruturação ao Ethereum, e suas regras de seleção de fork são baseadas no que o consenso Ethereum confirma para selecionar a "cadeia canônica". Se o Ethereum se reorganizar, o Rollup também se reorganizará.
• Liveness - No entanto, se o Rollup não tiver uma inclusão forçada e um mecanismo de substituição forçada do operador, os usuários do Rollup ainda não receberão o atributo de vivacidade do Ethereum;

O Rollup também pode fornecer aos usuários uma rota de escape para sair do Rollup, mas manter a capacidade de vetar usuários e impedir que depósitos entrem no Rollup (é assim que o Loopring funciona, por exemplo). Se o depósito permanecer sem processamento após um certo período de tempo, o usuário pode retirar os fundos bloqueados do contrato L1.

Este facto realça a importância de tais mecanismos.

Disponibilidade de dados e validade de status

Ao contrário da atividade e da anti-recombinação, os nós podem garantir a validade do DA e do estado sem fazer grandes suposições de limite (ou compensações de segurança entre os dois). Produtores de blocos majoritários mal-intencionados podem causar falhas de atividade e reorganização, mas não causarão falhas de DA ou de validade para nós completos ou nós leves do validador completo.

No entanto, os nós leves do validador de consenso são, naturalmente, afetados pela validade estatal de maiorias honestas e falhas de DA. Eles apenas acreditam em tudo o que o consenso diz. É por isso que DA e validade de estado são o que tornam as regras de confirmação de segurança acessíveis e realmente funcionam. Esta é muitas vezes a enorme diferença ideológica entre Rollups tradicionais e grandes blockchains que não colocam muita ênfase na verificação do usuário.

Em ordem, estas são muitas vezes as formas preferidas de equilibrar segurança e acessibilidade:

• Tornar a DAS e a prova de eficácia amplamente disponíveis;
• Se você não tiver DAS e/ou prova de validade, torne os nós completos amplamente acessíveis (ou seja, baixos requisitos de recursos, fáceis de executar, etc.);
• Se você não tem DAS e/ou prova de validade, e o nó completo é amplamente inacessível, então faça o nó leve do validador de consenso amplamente acessível e tenha um consenso de maioria honesta confiável;
• Visite o Infura;

Note que 2 (nó completo) é realmente o mais seguro. A verificação ZK é simples, mas os nós DAS fazem algumas suposições adicionais que os nós completos não fazem. No entanto, eles fornecem quase a mesma segurança que os nós completos e, com requisitos de recursos em uma fração disso, eles são escaláveis.

Os nós completos só precisam baixar todos os dados, então eles são 100% certos. Eles assinam o bloco apenas quando tudo está lá. Não foram feitas suposições sobre entidades externas.

O objetivo do DAS é alcançar uma segurança quase tão boa quanto os nós completos, embora com requisitos de recursos significativamente menores (ou seja, maior escala). Este artigo sobre os níveis de segurança de disponibilidade de dados de nó leve aborda bem isso.

Em resumo, você geralmente faz algumas suposições em torno da sincronização de rede e se há nós suficientes para reconstruir os dados. Se os produtores de blocos hostis ocultarem quaisquer dados, mesmo um pequeno grupo de nós leves honestos deve ser capaz de reconstruir blocos coletivamente. Existem também pressupostos sobre a divulgação seletiva de ações, em que os produtores de blocos hostis podem enganar um pequeno número de nós ligeiros individualmente, mas não colectivamente.

Essas suposições "N-em-2" (por exemplo, uma minoria honesta de nós pode garantir DAS) são muito vantajosas em relação à suposição "N/2" aproximada típica (por exemplo, 51% dos produtores de blocos podem levar à reorganização). Vitalik tem uma boa introdução a isso em seu post sobre o modelo de confiança.

No geral, a DA e a eficácia do estado não são "encomendadas" pelo Rollup como atividade e resistência recombinante. A validade do DA e do estado pode ser verificada diretamente pelo usuário, enquanto outros atributos dependem mais fortemente dos participantes consensuais da cadeia e seus incentivos.

Analise um exemplo de uma validação anterior da prova de Rollup:

• Publique a prova do Rollup de ZK em um contrato inteligente Ethereum, onde você executa um nó completo Ethereum e verifica implicitamente a prova;
• Envie a prova ZK de Rollup para o meu nó de luz de Rollup para verificar a prova diretamente;

Em ambos os casos, pode garantir a eficácia. Não importa onde você verifique, você não pode determinar sua eficácia. Ethereum não tem a mesma eficácia verdadeiramente "forçada" como nós Ethereum "forçar" propriedades anti-reestruturação ou ativas. A anti-reestruturação e a vitalidade dependem, em grande medida, de quem as obtém.

Considere um rollup baseado em cadeia de golpes:

• As regras de seleção de garfos do Rollup seguem a ponta da cadeia→ Se a cadeia for reorganizada, o Rollup também se reorganizará;
• O mecanismo de inclusão obrigatório do Rollup e a exclusão do sequenciador são aplicados por meio de contratos de ponte entre cadeias na cadeia de golpes→ Se o livro razão da cadeia de fraude parar, o mesmo acontece com o livro razão do rollup. Se a cadeia de golpes quiser censurar seu Rollup, então você será censurado;

O Rollup é capaz de expor regras de confirmação com os mesmos atributos de segurança de sua cadeia principal, que eles podem receber no máximo na taxa de consenso de sua cadeia de host (na verdade, geralmente será mais lento, dependendo da frequência com que o Rollup é publicado na cadeia principal).

Os rollups também podem fornecer um "caminho feliz" com regras de confirmação mais relaxadas (ou seja, sequenciadores) para uma melhor experiência do usuário, mas retêm reversões de transações em caso de falha. Se o sequenciador parar, você pode continuar em movimento. No entanto, este não é o caso se a sua cadeia depende inteiramente do seu próprio conjunto de validadores (ou seja, como uma cadeia de integração).

Escolher a cadeia principal do Rollup com sabedoria pode ter um impacto concreto nos atributos de segurança. É especialmente valioso alavancar uma cadeia de backchain com forte atividade (crescimento contábil + CR) e resistência à reorganização.

Pressupostos de segurança diferentes para diferentes períodos de tempo

Vejamos um exemplo simples. A Chain X está decidindo se deseja implantar como um Rollup em uma cadeia principal existente ou como seu próprio blockchain integrado.

O Rollup tem as seguintes características:

• 10 segundos de tempo de bloco;
• Nós de luz DAS são suportados
• Regras de confirmação de "alta segurança" para atividade e anti-reorganização (por exemplo, validadores confiáveis descentralizados, etc.) podem ser fornecidas;

O blockchain integrado tem as seguintes características:

• O tempo de saída do bloco é de 1 segundo;
• Nó de luz DAS e prova de validade podem ser implementados, quer seja lançado como um blockchain integrado ou como um rollup;
• Se um sequenciador centralizado for implementado - ele fornecerá regras de confirmação de "baixa segurança" sobre atividade e resistência à recombinação;
• Se implementar seu próprio consenso descentralizado (seja como um conjunto de sequenciadores de Rollup pré-confirmados ou como um conjunto de validadores de cadeia integrados), ele fornecerá regras de confirmação de "segurança média" para atividade e anti-reorganização;

A tabela a seguir fornece uma representação visual simplificada das melhores garantias de segurança que os usuários podem ter sob várias implementações (ou seja, eles usam as regras de reconhecimento mais fortes disponíveis). Em particular, concentramo-nos aqui na atividade e resistência à recombinação (porque assumimos que a cadeia só alcançará a prova de eficácia DAS+ nestes dois casos):

A "segurança máxima" do Rollup é maior do que sua "segurança em tempo real" porque a cadeia principal não pode nos garantir mais rápido do que seu próprio tempo de bloqueio. Embora você possa verificar se os pré-reconhecimentos do sequenciador são transições de estado válidas, você não pode garantir totalmente sua finalidade até que eles finalmente cheguem à camada DA.

Mas, como vimos, a implantação em uma rede principal forte de forma cumulativa aumenta a segurança. Eles podem alugar segurança na velocidade de sua cadeia principal. Fundamentalmente, não há como obter todos os atributos de segurança da cadeia principal mais rapidamente do que o consenso da própria cadeia principal.

No entanto, os usuários tendem a ser impacientes. Como resultado, o Rollup normalmente fornecerá uma pré-confirmação mais rápida, mas a garantia será menor durante esse período. O Rollup pode escolher um design de sequenciador equilibrado:

• Funcionalidade prática e eficiência. Por exemplo, sequenciadores centralizados podem fornecer pré-validação rápida e reduzir a sobrecarga operacional;
• Garantia forte. Por exemplo, um incrível conjunto de sequenciadores descentralizados pode fornecer melhor atividade em tempo real, mas ao custo de custos operacionais e latência mais altos (no caso mais extremo, você simplesmente deixa a camada DA lidar com a ordem do rollup, escolhendo não expor o caminho mais rápido);

Curiosamente, você pode argumentar que os pacotes cumulativos de pedidos L1 são menos ativos do que os sequenciadores centralizados, dependendo da sua escala de tempo. Até agora, falamos sobre atividade, incluindo-a em algum tipo de conceito de "tempo finito". No entanto, isso é inteiramente relativo e subjetivo. Em relação a quê? Quanto tempo demora?

Um rollup sequencial L1 puro só será incluído à velocidade dos blocos L1 (por exemplo, 10 segundos), e você não tem garantia de atividade entre esses blocos quando o mundo ao seu redor mudar. Portanto, depende do seu benchmark:

• Se linha de base = operação dentro do Rollup, o Rollup sequencial L1 pode fornecer melhor atividade. Ninguém mais na cadeia deve ser prometido até que a cadeia principal seja confirmada, para que todos estejam em pé de igualdade;
• Se linha de base = operação fora do Rollup - Rollup com pré-qualificação suave pode fornecer melhor atividade. A pré-confirmação é apenas uma opção gratuita, e você ainda recorre à garantia da cadeia principal na velocidade da cadeia principal, mas você pode obter uma garantia mais fraca enquanto isso. Se você não confia neles, basta aguardar a confirmação da cadeia principal. O mundo não congela entre blocos Ethereum e, para muitas aplicações, preços obsoletos entre longos tempos de bloqueio podem ser inaceitáveis;

Se você tentar implementar um rollup baseado em "real" sem pré-confirmação, é até possível que a pré-confirmação ocorra de qualquer maneira. Para os participantes, como construtores e validadores de Ethereum, há um incentivo financeiro para que eles mesmos assumam esse compromisso. É exatamente por isso que há discussão sobre como os construtores e partes interessadas do Ethereum estão tentando fornecer pré-confirmação rápida na camada base.

Aqui está uma última nota importante. Supondo que os usuários do Rollup possam voltar ao mesmo nível de atividade da cadeia principal, supondo que você possa forçar a inclusão inteiramente na velocidade do bloco da cadeia principal (por exemplo, se o ordenante do Rollup estiver revisando você, você pode forçar as transações a serem incluídas no próximo bloco Ethereum da cadeia principal).

Na prática, geralmente há um pequeno atraso. Se você permitir a inclusão obrigatória imediata, corre o risco de expor MEVs de censura lucrativos, juntamente com outras complexidades. No entanto, alguns projetos podem fornecer garantias de atividade quase em tempo real da cadeia principal (por exemplo, talvez à velocidade de vários blocos da cadeia principal em vez de um bloco).

Independentemente do calendário exato, a atividade final de absorção da cadeia principal é muito forte, e a utilização de uma cadeia principal forte como mecanismo de coordenação proporciona ameaças credíveis e direitos de saída. A mera exposição desta ameaça credível por si só torna altamente improvável que seja necessária para prevenir comportamentos maliciosos em primeiro lugar.

Por exemplo, se o usuário tiver um mecanismo confiável para sair à força ou até mesmo remover à força o operador, o sequenciador de Rollup centralizado não poderá extrair arbitrariamente o aluguel do usuário e bloqueá-lo. Esta é uma área geral discutida em Chris Goes em sua palestra sobre MEV Conversion Cost Edge e Slow Gaming.

É claro que atividades inesperadas também podem ocorrer, caso em que esse caminho de backup pode novamente ser muito valioso.

A prova não protege a cadeia, mas protege o usuário

Seguindo tudo isso, podemos ver que, para uma determinada regra de confirmação, acontece que é mais preciso proteger os diferentes "observadores" (usuários) do Rollup do que proteger o próprio "Rollup". A segurança do "Rollup" não existe como uma única medida específica.

Garantir a segurança do observador é, naturalmente, o mais importante, porque somos todos observadores da cadeia! Esta cadeia é o que os seus observadores dizem. Se você não pode observá-lo de forma segura, você tem que confiar em outra pessoa (como um verificador) para lhe dizer a "verdade" sobre ele. Mas não queremos confiar, queremos verificação→ queremos provas.

Para entender por que é importante distinguir entre "prova de cadeia" e "observador de cadeia de prova", considere o seguinte:

• Nós de luz - Nós de luz de rollup são mais seguros se houver provas, eles não precisam confiar na validade das palavras de ninguém;
• Nó completo - se houver uma prova, a segurança do nó completo do Rollup não aumentará ou diminuirá, você pode iniciar o Rollup ("rollup pessimista") sem uma ponte embutida ou mesmo qualquer prova, se você começar a enviar prova de validade, a segurança do nó completo não aumentará ou diminuirá;

Proven adiciona segurança aos observadores de cadeia (ou seja, nós leves) cuja validade não pode ser verificada diretamente. Não queremos que os usuários tenham que executar nós completos poderosos, então essas provas são importantes.

O atestado protege a ponte Rollup

A ponte de verificação do Rollup é um observador extremamente importante! As provas garantem a segurança da ponte!

Como em qualquer nó de luz típico, a ponte não pode verificar diretamente a validade do Rollup. Não acreditamos em maiorias honestas, mas protegemos pontes com provas. O protocolo de consenso para o banco de dados A (a camada DA) classifica os blobs de dados e, em seguida, verifica se a ponte verifica independentemente a validade da atualização correspondente para o banco de dados B (Rollup):

A ponte é um observador de outra cadeia, e cada ativo que cunha sempre carrega o pressuposto de segurança das regras de confirmação da ponte correspondente. A segurança das suas regras de confirmação pode ter implicações de grande alcance. É por isso que é tão importante construir pontes seguras (ou, idealmente, reduzir a necessidade de tantas pontes escalando ainda mais a execução de cadeia única em primeiro lugar).

Se você executar nós completos para a cadeia, as partes mal-intencionadas não poderão induzi-lo a aceitar transições de estado inválidas. No entanto, se a parte mal-intencionada tiver regras de confirmação diferentes, ela ainda pode falsificar a ponte. Se você tiver ativos garantidos por garantias na ponte, seus fundos podem ficar sem suporte. Nesse sentido, a falha de segurança da ponte de falsificação é "contagiosa".

Vamos considerar um velho cenário hipotético sobre o Terra:

• Terra tem seu próprio conjunto de validadores, seu token nativo é LUNA, e UST nativo pode ser emitido;
• Osmosis tem seu próprio conjunto de validadores, e seu token nativo é OSMO.
• Temos uma ponte padrão Terra ←→ Osmosis IBC onde cada lado executa o nó de luz do validador de consenso da outra cadeia (ou seja, cada lado da ponte depende de uma maioria honesta do conjunto de validadores da outra cadeia);
• Você executa seu próprio nó completo para cada cadeia como usuário;
• Referimo-nos a UST em Osmose sobre IBC como osmoUST;
• Referimo-nos a OSMO na Terra bridged via IBC como terraOSMO;
• Você possui terraOSMO no Terra;
• Você está fazendo LPs em um pool osmoUST/OSMO em Osmose;

Com o colapso do Terra, o preço do LUNA despenca e, eventualmente, o lucro do conjunto de validadores que teoricamente se torna malicioso excederá o valor do LUNA apostado, e o validador Terra pode assinar blocos inválidos e fazer o seguinte:

• Mint falso UST → cadeia cruzada para Osmosis para cunhar osmoUST, usá-lo para esgotar todos os pares de negociação osmoUST (por exemplo, tirar todo o OSMO do pool osmoUST / OSMO;
• A cunhagem de falsos terraOSMO → cadeia cruzada para osmose para retirar todas as garantias OSMO nativas bloqueadas na Osmose que suporta terraOSMO, todos os terraOSMO restantes no Terra agora não serão mais suportados;
• Bem, a segurança falha aqui:
• Full node (me) - meu nó completo reconhece os blocos Terra como inválidos e os rejeita, os validadores Terra não podem roubar minhas posições terraOSMO ou osmoUST/OSMO LP;
• Nó de luz (ponte) - a ponte apenas verifica se o consenso do Terra está assinado no bloco (não verificando transições de estado válidas) para não rejeitá-los, validadores Terra podem roubar OSMO colateral apoiando meu terraOSMO e drenar todo o OSMO do pool osmoUST / OSMO (deixando um monte de osmoUST inútil);

A ponte usa regras de reconhecimento com pressupostos de confiança mais fortes.

Os validadores do Terra não podem roubar grandes quantidades de ativos próprios do Terra de nós completos (eles não serão enganados), eles rejeitarão esses blocos. No entanto, os validadores podem enganar validadores de consenso em clientes leves (incluindo pontes), e é por isso que os erros de consenso afetam os ativos de cadeia cruzada.

Note que é importante que essas falhas não "infetem" o resto da cadeia, ou seja, a falha "infeta" os ativos da Osmose expostos à rota da ponte Terra, mas não há falha de segurança na cadeia da Osmose em si.

No entanto, obviamente queremos fazer a ponte entre as coisas (em geral, comunicação entre cadeias), seria ruim nos limitarmos a usar ativos nativos em sua cadeia principal, precisamos de cadeias para nos comunicarmos com segurança e fazer a ponte entre cadeias.

Como um experimento mental, a solução mais simples é fazer com que cada usuário execute nós completos de cada cadeia, o que inclui a própria ponte de cadeia cruzada. Lembre-se de que vimos algumas pontes de nó completo incorporadas unidirecionais:

• Os rollups Ethereum atualmente exigem que seus nós executem nós completos do Ethereum, e esses rollups compartilham o consenso do Ethereum; Namada (uma cadeia Tendermint separada, não uma cadeia Rollup) exigirá que seus nós executem nós completos do Ethereum, no entanto, Namada discorda do consenso do Ethereum (ou seja, não publica dados para Ethereum ou deriva seu estado com base nisso);

Isso funciona para nós completos do Ethereum, mas isso obviamente não escala. Você não pode começar a ter cada cadeia Cosmos apenas precisa executar nós completos para cada outra cadeia Cosmos. Essas pontes de nó completo bidirecionais não são dimensionadas, apenas aumentam os requisitos de hardware.

Felizmente, há uma opção mais escalável. Podemos implantar pontes para verificar completamente a validade do estado e DA de outra cadeia (além de ainda verificar o consenso).

Validade do Estado - Embora o IBC seja atualmente usado com a prova tradicional de consenso, ele pode ser modificado para adicionar prova de validade para cadeias de conexão, e agora as pontes não são falsificadas por transições de estado inválidas. Isso teria impedido exatamente o ataque descrito anteriormente, e se a ponte fosse capaz de verificar a validade da transição de estado, teria rejeitado o bloco do validador Terra como inválido.

Isso parece muito semelhante a como a ponte Rollup no Ethereum verifica se há provas de Rollup, exceto que também pode ser bidirecional.

DA - Além disso, uma cadeia pode exigir que seus nós executem nós leves DAS que conectam a cadeia. Por exemplo, você pode ter duas cadeias Cosmos que exigem seus próprios validadores para executar os nós leves DAS da outra cadeia (se cada cadeia implementar clientes leves DAS, que não são suportados atualmente). Uma vez feito isso, cada cadeia agora pode saber a validade e o DA uns dos outros sem ter que executar nós completos.

Para o Rollup, por definição, você possui todos os dados na cadeia principal, para que a ponte possa acessá-los. Os nós de rollup, por outro lado, executam nós da cadeia principal.

Cadeias dependentes e independentes

Vamos examinar nossos cinco atributos de segurança novamente, agora no contexto da observação da ponte de verificação do Rollup no Ethereum:

• Crescimento do livro-razão – validadores Ethereum podem forçar o livro-razão do Rollup a continuar a crescer (por exemplo, forçar transações de inclusão);
• Resistente à censura - validadores Ethereum podem forçar os operadores do Rollup a não censurar indefinidamente (por exemplo, forçar a inclusão de transações ou substituição de sequenciadores);
• Anti-reestruturação - A anti-reestruturação do Rollup está relacionada ao Ethereum. Se o Ethereum se reorganizar, todos os rollups no Ethereum serão reagrupados;
• Disponibilidade de dados - O DA do Rollup é garantido porque o Rollup é, por definição, derivado de dados confirmados pelo consenso da cadeia principal (onde o contrato do Rollup está localizado), o Rollup e a cadeia principal compartilham o consenso de fusão, o DA é uma condição de validade do próprio Ethereum, portanto, se os dados não estiverem disponíveis, então o próprio bloco Ethereum é inválido. A ponte pode acessar dados na cadeia principal sem adicionar pressupostos de confiança;
• Validade do estado - o contrato verificará a prova de validade da transição de estado do Rollup (ou aguardará a janela de contestação passar), o que prova que a atualização de estado declarada é um resultado válido da aplicação do STF do Rollup nos dados correspondentes confirmados na cadeia principal;

Observe que a segurança de uma ponte não é maximizada apenas por regras de confirmação superfortes para cadeias adicionais (por exemplo, uma ponte de validador completo para uma cadeia com um conjunto superconfiável de validadores). Se a ponte tiver as mesmas premissas de segurança que a cadeia principal, você poderá obter mais segurança quando ativos nativos de cadeia cruzada.

Vitalik fornece um exemplo ilustrativo útil:

"Você transfere 100 ETH para uma ponte sobre Solana e obtém 100 Solana-WETH, e o Ethereum recebe 51% de ataque. O atacante deposita um monte de seu ETH em Solana-WETH e, em seguida, retoma a transação no lado Ethereum assim que o lado Solana confirma. O contrato Solana-WETH não é mais totalmente suportado, e talvez seu 100 Solana-WETH agora valha apenas 60 ETH. Mesmo com uma ponte perfeita baseada em ZK-SNARK validando totalmente o consenso, ela ainda é vulnerável a um ataque de 51% como este.

Portanto, é sempre mais seguro manter ativos nativos Ethereum em Ethereum ou Solana ativos nativos em Solana do que manter ativos nativos Ethereum em Solana ou Solana ativos nativos em Ethereum. Neste contexto, "Ethereum" refere-se não apenas à cadeia subjacente, mas também a qualquer L2 apropriado construído sobre ela.

Se o Ethereum for 51% atacado e se recuperar, o Arbitrum e o Optimism também se recuperarão, portanto, mesmo que o Ethereum seja atacado por 51%, os aplicativos "cross-rollup" que salvam estado no Arbitrum e no Optimism certamente permanecerão consistentes. Se o Ethereum não tivesse sido 51% atacado, não haveria como fazer um ataque de 51% ao Arbitrum e ao Otimismo, respectivamente. Portanto, ainda é completamente seguro manter ativos emitidos pela Otimismo baseada em Arbitrum.

Você pode substituir Solana por qualquer cadeia que quiser - até mesmo uma cadeia hipotética onde você supera um validador Ethereum em termos de confiança e, fundamentalmente, quaisquer suposições de segurança são aditivas quando você fala sobre ativos de cadeia cruzada com seu livro razão de registro (por exemplo, ETH de Ethereum), e sempre há a possibilidade de uma cadeia conectada reorganizar ou falha de atividade.

No entanto, as cadeias com consenso fundido (ou seja, rollups que partilham o consenso da sua cadeia principal) podem contornar estes pressupostos de segurança adicionais. As pontes de cadeia cruzada entre estas diferentes regiões podem ter a mesma atividade final e propriedades anti-recombinação que a própria cadeia principal. O consenso compartilhado minimiza as suposições de confiança entre cadeias dentro dessa zona de segurança compartilhada.

O que são pressupostos de segurança razoáveis depende de si. Na verdade, não houve uma falha de consenso semelhante entre as grandes cadeias. Isto seria óbvio e dispendioso, mas poderia ser um pressuposto mais forte sobre a ligação de cadeias mais fracas.

Há também algumas desvantagens em vincular uma cadeia Rollup à cadeia principal. Vamos comparar dois cenários de cadeia cruzada, em ambos os casos temos duas cadeias que usam a ponte de cadeia cruzada do validador completo bidirecional:

• Dependência - a cadeia remota (i.e. Rollup) partilha o consenso da cadeia principal (i.e. a camada DA) e deriva o seu próprio estado a partir dos dados na cadeia principal, a cadeia remota deve bifurcar-se com a cadeia principal e determinar a sua finalidade com base na cadeia principal;
• Independentes - Estas cadeias têm o seu próprio consenso independente, não derivam o seu próprio estado com base em dados de outras cadeias. Eles não compartilham uma relação de cadeia remota (ou seja, Rollup) ←→ cadeia principal (ou seja, camada DA). Não se reagrupam e não dependem da atividade uns dos outros;
• Curiosamente, estes são bons e maus:
• Ruim - Reorganizar sua cadeia com outras cadeias ou ter falhas de atividade pode soar como uma desvantagem à primeira vista, por que minha cadeia está tendo problemas porque sua cadeia está quebrada?
• Bom - se essa divergência causar sérios problemas em sua cadeia, isso é realmente um benefício importante (por exemplo, se você tiver um grande número de ativos de cadeia cruzada da cadeia de origem, então ela será reorganizada da perspetiva de sua ponte de cadeia cruzada, deixando garantias sem garantia), a cadeia e sua ponte de cadeia cruzada precisam ser consistentes entre si;

Da mesma forma, lock-ins e busca excessiva de aluguel têm potenciais efeitos positivos e negativos, destacando por que uma camada de base neutra e resistente à censura é tão importante:

• Bom - Uma boa cadeia principal protege os usuários do Rollup dos operadores do Rollup que extraem muito valor deles, impondo privilégios de saída;
• Ruim - Backchains ruins podem inflar arbitrariamente o preço e extrair esse valor do Rollup e de seus próprios usuários;
• Prova de submissão + execução de DAS em ambas as direções em vez de compartilhar uma cadeia principal comum também tem algumas ineficiências:
• Você não quer exigir que seu nó execute um monte de nós leves DAS de outras cadeias, e tem que adicionar manualmente novas cadeias, executar DAS em uma enorme camada DA compartilhada é muito mais eficiente;
• É ineficiente para cada cadeia verificar a validade para muitas cadeias diferentes, no entanto, é teoricamente possível agregar provas entre várias cadeias, de modo que todo o cluster de cadeias só precisa publicar uma prova para a cadeia;

Há compensações e benefícios aqui, mas também tenha em mente que há uma enorme dependência de caminho de onde estão os ativos interessantes, e se você quiser usar um monte de ativos nativos do Ethereum (incluindo aqueles em seu Rollup), faz sentido enraizar sua cadeia no Ethereum e suas pontes entre cadeias.

Conclusão

"Segurança de herança de rollups" é uma boa abreviação, mas lembre-se de que estes são os pontos-chave que realmente queremos dizer:

• O Rollup paga aluguel à sua cadeia principal, como o Ethereum, pelos recursos que consome (DA);
• O rollup pode expor regras de confirmação com propriedades de segurança até à cadeia principal (ou seja, os utilizadores podem obter as mesmas garantias de segurança que quando operam na própria cadeia principal);
• Os utilizadores obtêm estes atributos de segurança da cadeia principal à velocidade do consenso da cadeia principal;
• Se os usuários do Rollup quiserem ser mais rápidos do que a confirmação fornecida pela cadeia principal, eles podem usar regras de confirmação, que fazem suposições de segurança temporárias adicionais;
• O observador (ou seja, o usuário) interage com o Rollup através de regras de confirmação, e a ponte de verificação com a suposição de menor confiança é um observador (opcional, mas muito valioso);

Agora, considere os benefícios da implantação do Rollup na cadeia de integração:

Segurança do usuário - Quer você queira implementar quaisquer pontes entre cadeias ou não, o Rollups pode alugar DA de sua cadeia principal e recuperar seu consenso, o que permite que o Rollup exponha regras de confirmação que correspondem à cadeia principal para seus usuários sem ter que chegar a seu próprio consenso;

Segurança entre cadeias - O Rollup pode construir cadeias cruzadas dentro do domínio de segurança partilhado da cadeia principal (ou seja, a própria cadeia principal e o seu Rollup), e as suas propriedades de segurança são comparáveis à operação na própria cadeia principal;

Devemos ver que, na verdade, são duas faces da mesma moeda, e o Rollup apenas permite que a cadeia forneça regras de confirmação, e sua segurança pode atingir a segurança da cadeia principal. Tanto as pontes de cadeia cruzada como os utilizadores normais são observadores de cadeias com determinadas regras de reconhecimento. As pontes são talvez os "observadores" mais importantes nestas cadeias, porque a sua segurança tem implicações de grande alcance.

Quando tentamos criar um sistema seguro, temos de nos preocupar com a segurança de determinadas regras de confirmação, bem como com a sua acessibilidade. Se a maioria dos observadores (usuários) que interagem com essas cadeias estiver fora de alcance, as regras de confirmação de segurança não ajudam muito.

Embora hoje associemos DAS e provas de validade ao Rollup, eles são conceitos logicamente separados. Qualquer cadeia pode integrar essas tecnologias, e a distinção entre o que é um rollup ou não é um rollup começa a quebrar no final do jogo (ou seja, para um único rollup integrado, ele pode ter camadas de execução e DA logicamente separadas sob um protocolo).

No entanto, o "rollup tradicional" e as camadas de DA claramente dominam essas tecnologias de verificação e dimensionamento atualmente.