Como existe uma falta de interpretação profissional de artigos ou materiais relacionados aos protocolos Layer2, especialmente para Arbitrum e OP Rollup, na comunidade chinesa, este artigo visa preencher esta lacuna explicando o mecanismo operacional do Arbitrum. Devido à complexidade do próprio Arbitrum, o texto completo, mesmo depois de simplificado ao máximo, ainda ultrapassa 10.000 palavras. Portanto, está dividido em duas partes, e recomenda-se que seja salvo e compartilhado como material de referência.”

Visão geral do sequenciador de rollup

O princípio do escalonamento Rollup pode ser resumido em dois pontos:

Otimização de Custos: Transfira a maior parte das tarefas de computação e armazenamento para a Camada 2, que é operada em L1. L2 é executado principalmente em um único servidor, conhecido como sequenciador/operador, formando uma cadeia separada.

O sequenciador aparece quase como um servidor centralizado em termos de percepção, abandonando a descentralização na ‘trindade impossível do blockchain’ para obter vantagens em TPS e custo. Os usuários podem usar L2 para lidar com instruções de transação em vez do Ethereum, com custos muito mais baixos em comparação com as transações no Ethereum.

(Fonte: Rede BNB)

Garantia de segurança: O conteúdo da transação e o estado pós-transação em L2 são sincronizados com Ethereum L1 e sua validade é verificada por meio de contratos de transição de estado. Ao mesmo tempo, o Ethereum mantém o histórico do L2, portanto, mesmo que o sequenciador trave permanentemente, outros podem reconstruir todo o estado do L2 por meio dos registros do Ethereum.

Fundamentalmente, a segurança do Rollup depende do Ethereum. Se o sequenciador não conhecer a chave privada de uma conta, ele não poderá iniciar transações em nome dessa conta ou manipular o saldo de ativos da conta (mesmo que tentasse, seria rapidamente detectado).

Embora o sequenciador, como hub central, tenha um aspecto centralizado, em soluções Rollup maduras, o sequenciador centralizado só pode se envolver em atividades maliciosas leves, como censura de transações ou falhas maliciosas. Num cenário ideal de Rollup, existem medidas correspondentes para restringir tais ações, como retiradas compulsórias ou sequenciamento de provas para mecanismos anticensura.

(O protocolo Loopring define uma função de retirada forçada no código-fonte do contrato em L1 para os usuários ligarem)

Os mecanismos de verificação de estado para evitar ações maliciosas por sequenciadores Rollup são divididos em duas categorias: Prova de Fraude e Prova de Validade. As soluções de rollup que usam Fraud Proof são chamadas de OP Rollup (Optimistic Rollup, OPR), enquanto aquelas que usam Validity Proof são frequentemente chamadas de ZK Rollup (Zero-knowledge Proof Rollup, ZKR) em vez de Validity Rollup devido à bagagem histórica.

O Arbitrum One é um OPR típico, implantado em L1 com contratos que não validam ativamente os dados submetidos, assumindo de forma otimista que os dados estão corretos. Se houver um erro nos dados enviados, os nós validadores L2 iniciarão ativamente um desafio.

Portanto, OPR implica uma suposição de confiança: a qualquer momento, existe pelo menos um nó validador L2 honesto. Por outro lado, os contratos ZKR validam de forma ativa e econômica os dados enviados pelo sequenciador por meio de cálculos criptográficos.

(Método de operação de rollup otimista)

(Método de operação ZK Rollup)

Este artigo fornece uma introdução detalhada ao projeto líder em Optimistic Rollup – Arbitrum One, cobrindo todos os aspectos de todo o sistema. Depois de lê-lo com atenção, você terá um conhecimento profundo de Arbitrum e Optimistic Rollup/OPR.

Componentes principais e fluxo de trabalho da arbitragem

Contratos principais:

Os contratos mais importantes no Arbitrum incluem SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, etc. Eles serão detalhados nas seções seguintes.

Sequenciador:

O sequenciador recebe as transações do usuário, classifica-as, calcula os resultados da transação e retorna rapidamente (geralmente <1s) os recibos aos usuários. Os usuários geralmente veem suas transações em L2 em poucos segundos, proporcionando uma experiência semelhante às plataformas Web2.

Simultaneamente, o sequenciador transmite imediatamente o último bloco L2 gerado fora da cadeia Ethereum. Qualquer nó da Camada2 pode receber esses blocos L2 de forma assíncrona. No entanto, estes blocos L2 não têm finalidade neste ponto e podem ser revertidos pelo sequenciador.

A cada poucos minutos, o sequenciador compacta os dados de transação L2 classificados, agrega-os em lotes e os envia ao contrato SequencerInbox na Camada 1 para garantir a disponibilidade dos dados e a operação do protocolo Rollup. Geralmente, os dados L2 submetidos à Camada 1 não podem ser revertidos e podem ter determinismo final.

A partir do processo acima, podemos resumir: a Camada 2 possui sua própria rede de nós, mas o número desses nós é escasso e geralmente não existe um protocolo de consenso comumente usado por cadeias públicas, por isso fornece uma segurança muito fraca. Deve confiar no Ethereum para garantir a confiabilidade da divulgação de dados e a eficácia das transições de estado. sexo.

Protocolo de acumulação de arbitragem:

Esta é uma série de contratos que definem a estrutura do bloco RBlock da cadeia Rollup, o método de continuação da cadeia, o lançamento do RBlock e o processo do modo de desafio. Observe que a cadeia Rollup mencionada aqui não é o livro-razão da Camada 2 que todos entendem, mas uma “estrutura de dados semelhante a uma cadeia” abstrata criada independentemente pela Arbitrum One para implementar o mecanismo à prova de fraude.

Um RBlock pode conter os resultados de vários blocos L2 e os dados também são muito diferentes. Sua entidade de dados RBlock é armazenada em uma série de contratos no RollupCore. Se houver algum problema com um RBlock, o Validador desafiará o remetente do RBlock.

Validador:

Os nós validadores do Arbitrum são, na verdade, um subconjunto especial de nós completos da Camada 2 e atualmente têm acesso a uma lista de permissões.

O Validator cria um novo RBlock (bloco Rollup, também chamado de assertion) com base no lote de transações enviado pelo sequenciador ao contrato SequencerInbox, além de monitorar o status da cadeia Rollup atual e contestar os dados incorretos enviados pelo sequenciador.

O Active Validator precisa apostar ativos na cadeia ETH com antecedência. Às vezes também o chamamos de Staker. Embora os nós da Camada 2 que não fazem stake também possam monitorar a dinâmica de operação do Rollup e enviar alarmes anormais aos usuários, eles não podem intervir diretamente nos dados de erro enviados pelo sequenciador na cadeia ETH.

Desafio:

As etapas básicas podem ser resumidas como múltiplas rodadas de segmentação interativa e prova em uma etapa. No processo de segmentação, as partes desafiadoras primeiro conduzem múltiplas rodadas de segmentação nos dados de transação problemáticos até decomporem as instruções do código de operação problemático e realizarem a verificação. O paradigma de “múltiplas rodadas de prova de segmentação em uma etapa” é considerado pelos desenvolvedores do Arbitrum como a implementação de prova de fraude que mais economiza gás. Todos os links estão sob controle contratual e nenhuma parte pode trapacear.

Período do desafio:

Devido à natureza otimista do OP Rollup, após cada RBlock ser enviado à cadeia, o contrato não é verificado ativamente, deixando um período de janela para o verificador falsificar. Este período de janela é o período de desafio, que dura 1 semana na rede principal do Arbitrum One. Após o término do período do desafio, o RBlock será finalmente confirmado. Somente as mensagens correspondentes passadas de L2 para L1 dentro do bloco (como operações de retirada realizadas através da ponte oficial) podem ser liberadas.

ArbOS, Geth, WAVM:

A máquina virtual usada pela Arbitrum é chamada AVM, que inclui Geth e ArbOS. Geth é o software cliente mais comumente usado no Ethereum, e a Arbitrum fez pequenas modificações nele. ArbOS é responsável por todas as funções especiais relacionadas ao L2, como gerenciamento de recursos de rede, geração de blocos L2, trabalho com EVM, etc. Consideramos a combinação dos dois como um Native AVM, que é a máquina virtual utilizada pela Arbitrum. WAVM é o resultado da compilação do código AVM no Wasm. No processo de contestação da Arbitrum, a última “prova em uma etapa” verifica a instrução WAVM.

Aqui, podemos usar a figura a seguir para representar o relacionamento e o fluxo de trabalho entre os componentes acima:

Ciclo de vida da transação em L2

O fluxo de processamento de uma transação em L2 é o seguinte:

1. Os usuários enviam instruções de negociação ao sequenciador.

2. O sequenciador primeiro verifica as transações a serem processadas em assinaturas digitais e outros dados, elimina transações inválidas e executa sequências e cálculos.

3. O sequenciador envia o recibo da transação ao usuário (geralmente muito rápido), que é apenas o “pré-processamento” realizado pelo classificador na cadeia ETH. Está no estado de Soft Finality e não é confiável. Mas para os usuários (a maioria dos usuários) que confiam no sequenciador, eles podem estar otimistas de que a transação foi concluída e não será revertida.

4. O sequenciador compacta altamente os dados da transação original pré-processados e os encapsula em um lote.

5. De vez em quando (afetado por fatores como volume de dados e congestionamento de ETH), o sequenciador publicará lotes de transações no contrato da Caixa de entrada do sequenciador em L1. Neste ponto, pode-se considerar que a transação tem Finalidade Dura.

Contrato de caixa de entrada do sequenciador

O contrato receberá o lote de transações enviado pelo sequenciador para garantir a disponibilidade dos dados. Se olharmos isso de uma forma mais profunda, os dados do lote no Sequencer Inbox registram completamente as informações de entrada da transação da Camada2. Mesmo que o sequenciador esteja permanentemente inativo, qualquer um pode restaurar o estado atual da Camada 2 com base no registro do lote e substituir o sequenciador com defeito/em execução.

Para entender fisicamente, o L2 que vemos é apenas a projeção do lote no SequencerInbox, e a fonte de luz é o STF. Como a fonte de luz STF não muda facilmente, a forma da sombra é determinada apenas pelo lote que atua como objeto.

O contrato do Sequencer Inbox é chamado de fast box. O sequenciador envia especificamente transações pré-processadas para ele, e somente o sequenciador pode enviar dados para ele. A caixa rápida correspondente é a caixa lenta Delayer Inbox, e sua função será descrita no processo subsequente.

O Validador sempre monitorará o contrato da Caixa de Entrada do Sequenciador. Sempre que o sequenciador liberar um lote para o contrato, um evento on-chain será produzido. Após o Validador detectar a ocorrência deste evento, ele fará o download dos dados do lote. Após a execução local, o RBlock será emitido para o contrato do protocolo Rollup na cadeia ETH.

O contrato ponte da Arbitrum possui um parâmetro denominado acumulador, que registra o lote L2 recém-enviado, bem como o número e as informações das transações recém-recebidas na caixa de entrada lenta.

（O sequenciador envia lotes continuamente para a caixa de entrada do sequenciador）

（As informações específicas do lote; o campo de dados corresponde aos dados do lote. O tamanho desta parte dos dados é muito grande e a captura de tela não é totalmente exibida.）

O contrato SequencerInbox tem duas funções principais:

adicionar sequenciador L2Batch da origem()

O sequenciador chamará essa função sempre para enviar dados do lote ao contrato do Sequencer Inox.

forçar inclusão()

Esta função pode ser chamada por qualquer pessoa e é usada para implementar transações resistentes à censura. A forma como esta função entra em vigor será explicada em detalhes posteriormente, quando falarmos sobre o contrato Delayed Inbox.

As duas funções acima chamarão 'bridge.enqueueSequencerMessage()' para atualizar o parâmetro do acumulador no contrato da ponte.

Preços do gás

Obviamente, as transações L2 não podem ser gratuitas, porque isso levará a ataques DoS. Além disso, existem custos operacionais para o próprio classificador L2 e haverá custos indiretos para o envio de dados em L1. Quando um usuário inicia uma transação dentro da rede da Camada 2, a estrutura de taxas do gás seria a seguinte:

Custos de publicação de dados incorridos pela ocupação de recursos da Camada 1

Esse custo vem principalmente dos lotes enviados pelo sequenciador (cada lote tem muitas transações do usuário) e, em última análise, o custo é dividido igualmente entre os iniciadores da transação. O algoritmo de precificação de taxas gerado pela liberação de dados é dinâmico, e o sequenciador definirá o preço com base no status recente de lucros e perdas, tamanho do lote e preço atual do gás Ethereum.

O custo incorrido pelos usuários que ocupam recursos da Camada 2

É estabelecido um limite de gás para TPS para garantir a operação estável do sistema (atualmente 7 milhões no Arbitrum One). Os preços de orientação do gás para L1 e L2 são rastreados e ajustados pela ArbOS, e a fórmula não está detalhada aqui por enquanto.

Embora o processo específico de cálculo do preço do gás seja relativamente complicado, os usuários não precisam estar cientes desses detalhes e podem sentir claramente que as taxas de transação Rollup são muito mais baratas do que a rede principal ETH.

À prova de fraude otimista

Lembrando o que foi dito acima, L2 é na verdade apenas a projeção do lote de entrada da transação enviado pelo sequenciador na caixa rápida, ou seja:

Entradas de transação -> STF -> Saídas de estado. A entrada foi apurada e o STF permanece inalterado, portanto o resultado da saída também é apurado. O sistema de prova de fraude e protocolo Arbitrum Rollup é um sistema que publica a raiz do estado de saída na forma de RBlock (também conhecido como asserção) para L1 e realiza prova otimista sobre ela.

Em L1, há dados de entrada publicados pelo sequenciador e status de saída publicados pelo verificador. Vamos considerar com cuidado: é necessário publicar o status da Camada 2 na cadeia?

Como a entrada determinou completamente a saída e os dados de entrada são visíveis publicamente, parece redundante enviar o estado do resultado da saída? Mas esta ideia ignora a real necessidade de liquidação de estado entre os dois sistemas L1 e L2, ou seja, o comportamento de retirada de L2 para L1 requer prova do estado.

Ao construir o Rollup, uma das ideias principais é colocar a maior parte da computação e do armazenamento em L2 para evitar o alto custo de L1. Isso significa que L1 não conhece o status de L2, apenas ajuda L2. O sequenciador publica os dados de entrada de todas as transações, mas não é responsável pelo cálculo do estado de L2.

O comportamento de retirada consiste essencialmente em desbloquear os fundos correspondentes do contrato L1, transferi-los para a conta L1 do usuário ou completar outras coisas seguindo a mensagem cross-chain dada por L2.

Neste momento, o contrato da Camada 1 perguntará: Qual é o seu status na Camada 2 e como provar que você realmente possui os ativos que declara serem transferidos? Neste momento, o usuário deve fornecer a Prova Merkle correspondente, etc.

Portanto, se construirmos um Rollup sem função de retirada, é teoricamente possível não sincronizar o estado com L1, e não há necessidade de um sistema de prova de estado como a prova de fraude (embora possa causar outros problemas). Mas em aplicações reais, isto obviamente não é viável.

Na chamada prova otimista, o contrato não verifica se o status da saída submetido ao L1 está correto, mas acredita com otimismo que tudo está correto. O sistema de prova otimista pressupõe que existe pelo menos um Validador honesto a qualquer momento. Se ocorrer um estado incorreto, ele será contestado por meio de prova de fraude.

A vantagem deste projeto é que não há necessidade de verificar ativamente cada RBlock emitido para L1 para evitar desperdício de gás. Na verdade, para OPR, não é realista verificar cada afirmação, porque cada bloco R contém um ou mais blocos L2 e cada transação deve ser reexecutada em L1. Não é diferente de executar transações L2 diretamente em L1, o que torna a expansão da Camada 2 sem sentido.

O ZKR não tem esse problema, porque o ZK Proof é conciso. Ele só precisa verificar uma Prova muito pequena e não há necessidade de realmente executar muitas transações correspondentes à Prova. Portanto, a ZKR não opera de forma otimista. Cada vez que o status for divulgado, haverá um contrato de Verifier para verificação matemática.

Embora a prova de fraude não possa ser tão concisa quanto a prova de conhecimento zero, a Arbitrum usa um processo interativo baseado em turnos de “multi rodadas de prova de segmentação em uma etapa”. No final, o que precisa ser provado é apenas um único código de operação da máquina virtual, e o custo é relativamente pequeno.

Protocolo de acúmulo

Vamos primeiro dar uma olhada na entrada para iniciar desafios e iniciar provas, ou seja, como funciona o protocolo Rollup.

O contrato principal do protocolo Rollup é RollupProxy.sol, que usa uma rara estrutura de agente duplo, garantindo ao mesmo tempo que a estrutura de dados é consistente. Um agente corresponde a duas implementações de RollupUserLogic.sol e RollupAdminLogic.sol, que não podem ser bem analisadas por ferramentas como Scan.

Além disso, o contrato ChallengeManager.sol é responsável por gerenciar desafios, e os contratos da série OneStepProver são usados para determinar provas de fraude.

(Fonte: site oficial L2BEAT)

Isso mostra o registro de uma série de RBlocks (também conhecidos como assertions), em RollupProxy, enviados por diferentes Validadores, que são as caixas da figura abaixo: Verde confirmado, azul não confirmado, amarelo falsificado.

RBlock contém o estado final após a execução de um ou mais blocos L2 desde o último RBlock. Esses RBlocks formam uma cadeia de rollup formal (observe que o próprio razão L2 é diferente). Em circunstâncias otimistas, esta cadeia de rollup não deve ter bifurcações, porque uma bifurcação significa que um validador enviou blocos de rollup conflitantes.

Para propor ou concordar com uma afirmação, o verificador precisa primeiro apostar uma certa quantidade de ETH para a afirmação e se tornar um Staker. Dessa forma, quando ocorrer uma prova de contestação/fraude, a garantia do perdedor será reduzida. Esta é a base económica para garantir o comportamento honesto do verificador.

O bloco azul nº 111 no canto inferior direito da imagem acabará sendo cortado porque seu bloco pai nº 104 (amarelo) está errado.

Além disso, o verificador A propôs o Bloco Rollup nº 106, mas B discordou e contestou.

Após B iniciar o desafio, o contrato ChallengeManager será responsável por verificar a segmentação das etapas do desafio:

1. A segmentação é um processo no qual ambas as partes se revezam para interagir. Uma parte segmenta os dados históricos contidos em um determinado bloco cumulativo e a outra parte aponta qual parte do fragmento de dados é problemática, um processo semelhante à dicotomia (na verdade, N/K) que restringe contínua e gradualmente o escopo.

2. Depois disso, você pode continuar a localizar a transação e o resultado que são problemáticos e, em seguida, subdividi-los em uma instrução de máquina contestada na transação.

3. O contrato ChallengeManager apenas verifica se os “fragmentos de dados” gerados após a segmentação dos dados originais são válidos.

4. Quando o desafiante e a parte desafiada localizam a instrução de máquina que será desafiada, o desafiante chama a função 'oneStepProveExecution()' e envia uma prova de fraude de uma etapa para provar que há um problema com o resultado da execução desta instrução de máquina.

Prova em uma etapa

A prova em uma etapa é o núcleo de toda a prova de fraude da Arbitrum. Vamos dar uma olhada no que a prova em uma etapa prova especificamente.

Isso requer primeiro entender o WAVM. Wasm Arbitrum Virtual Machine é uma máquina virtual compilada pelo módulo ArbOS e pelo módulo principal Geth (cliente Ethereum). Como L2 é muito diferente de L1, o núcleo Geth original teve que ser levemente modificado e funcionar com ArbOS.

Portanto, a transição de estado em L2 é na verdade um trabalho conjunto do ArbOS+Geth Core.

O cliente de nó da Arbitrum (sequenciador, verificador, nó completo, etc.) compila o programa de processamento ArbOS+Geth Core mencionado acima em código de máquina nativo que o host do nó pode processar diretamente (para x86/ARM/PC/Mac/etc.).

Se você alterar o idioma de destino obtido após a compilação para Wasm, obterá o WAVM usado pelo verificador ao gerar as provas de fraude, e o contrato para verificar a prova em uma etapa também simula as funções da máquina virtual WAVM.

Então, por que ele precisa ser compilado no bytecode Wasm ao gerar provas de fraude? A principal razão é que, para verificar o contrato à prova de fraude em uma etapa, é necessário usar o contrato inteligente Ethereum para simular uma máquina virtual VM que pode lidar com um determinado conjunto de conjuntos de instruções, e o WASM é fácil de implementar simulação em o contrato.

No entanto, o WASM é executado um pouco mais lento que o código de máquina nativo, portanto, os nós/contratos da Arbitrum usarão WAVM apenas ao gerar e verificar provas de fraude.

Após as rodadas anteriores de segmentação interativa, a prova de uma etapa finalmente provou a instrução de uma etapa no conjunto de instruções WAVM.

Como pode ser visto no código abaixo, OneStepProofEntry primeiro determina a qual categoria pertence o código de operação da instrução a ser provada e, em seguida, chama o provador correspondente, como Mem, Math, etc., para passar a instrução de uma etapa para o contrato de provador.

O resultado final afterHash será retornado ao ChallengeManager. Se o hash for inconsistente com o hash após a operação da instrução registrada no Rollup Block, o desafio será bem-sucedido. Se forem consistentes, significa que não há problema com o resultado da execução desta instrução registrada no Rollup Block e o desafio falhou.

Na parte 2, analisaremos o Arbitrum e até mesmo o módulo de contrato que lida com funções de mensagens/pontes entre a Camada 2 e a Camada 1, e esclareceremos ainda mais como uma verdadeira Camada 2 deve alcançar resistência à censura.

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [WeChat]. Todos os direitos autorais pertencem ao autor original [Luo Benben]. 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.