Encaminhar o Título Original：

Este artigo fornece uma interpretação técnica do Arbitrum One por Luo Benben (罗奔奔), ex-embaixador técnico da Arbitrum e ex-sócio-fundador da Goplus Security, uma empresa de auditoria de automação de contratos inteligentes.

Devido à falta de interpretação profissional de Arbitrum e até OP Rollup em artigos ou materiais chineses relacionados à Camada 2, este artigo tenta preencher a lacuna nesse campo popularizando o mecanismo operacional do Arbitrum. Como a estrutura do Arbitrum em si é muito complexa, embora o texto completo tenha sido simplificado o máximo possível, ainda ultrapassa 10.000 palavras, então ele é dividido em duas partes. É recomendado coletá-lo e encaminhá-lo como referência!

Introdução breve ao sequenciador de Rollup

O princípio da expansão Rollup pode ser resumido em dois pontos:

Otimização de custos: Transferir a maioria das tarefas de computação e armazenamento para o offchain L1, ou seja, L2. L2 é principalmente uma cadeia que funciona em um único servidor, ou seja, o sequenciador / operador.

O sequenciador está próximo de um servidor centralizado, de certa forma. No 'triângulo impossível da blockchain', a 'descentralização' é abandonada em troca de TPS e vantagens de custo. Os usuários podem permitir que a L2 processe instruções de transação em vez do Ethereum, e o custo é muito menor do que negociar no Ethereum.

(Fonte: BNB Chain)

Garantia de segurança: O conteúdo da transação e o estado resultante na Camada 2 são sincronizados com a Camada 1 do Ethereum, onde sua validade é verificada por meio de contratos. Enquanto isso, o Ethereum mantém os registros históricos da L2, então mesmo que o sequenciador falhe permanentemente, outros podem reconstruir todo o estado da L2 a partir dos registros no Ethereum.

Fundamentalmente, a segurança do Rollup é baseada no Ethereum. Se um sequenciador não conhece a chave privada de uma conta, não pode iniciar transações em nome dessa conta ou manipular o saldo de ativos dessa conta (mesmo que tente, seria rapidamente detectado).

Embora o sequenciador, como o centro do sistema, possa ter uma tonalidade centralizada, em soluções Rollup maduras, um sequenciador centralizado só pode se envolver em comportamentos maliciosos suaves, como censura de transações ou falhas maliciosas. No entanto, em soluções Rollup ideais, existem medidas correspondentes para conter tais comportamentos (como retiradas forçadas ou provas de classificação como mecanismos anti-censura).

(O protocolo Loopring define uma função de saque forçado no código-fonte do contrato em L1 para que os usuários possam chamar)

Para evitar comportamentos maliciosos por parte dos sequenciadores Rollup, existem dois tipos de métodos de verificação de estado: Prova de Fraude e Prova de Validade. As soluções Rollup que utilizam Prova de Fraude são chamadas de Rollup Otimista (OPR), enquanto aquelas que utilizam Prova de Validade são frequentemente referidas como ZK Rollup (Rollup de Prova de Conhecimento Zero, ZKR), em vez de Rollup de Validade, devido a questões históricas.

Arbitrum One é um OPR típico, implantado em contratos L1, que não validam ativamente os dados enviados, mas assumem otimistamente que os dados estão corretos. Se houver erros nos dados enviados, os validadores L2 iniciarão desafios.

Portanto, OPR também implica uma suposição de confiança: há pelo menos um nó validador L2 honesto em qualquer momento dado. Por outro lado, os contratos ZKR verificam proativamente e de forma eficiente os dados enviados pelo sequenciador por meio de cálculos criptográficos.

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

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

Este artigo fornecerá uma introdução detalhada ao principal projeto em Optimistic Rollup — Arbitrum One, cobrindo todos os aspectos do sistema. Após uma leitura cuidadosa, você obterá um entendimento profundo do Arbitrum e do Optimistic Rollup (OPR).

Componentes principais e fluxo de trabalho do Arbitrum:

Contratos Principais:

Os contratos mais importantes no Arbitrum incluem SequencerInbox, DelayedInbox, Portões L1, Portões L2, Caixa de Saída, RollupCore, Bridge, etc. Esses serão detalhados posteriormente.

Sequenciador:

Recebe transações de usuários e as sequencia, calcula os resultados das transações e retorna rapidamente (geralmente <1s) os recibos aos usuários. Os usuários geralmente podem ver suas transações confirmadas no L2 em segundos, proporcionando uma experiência semelhante à Web2.

Além disso, o sequenciador transmite imediatamente os últimos Blocos L2 gerados sob a cadeia Ethereum, que qualquer nó da Camada 2 pode receber de forma assíncrona. No entanto, neste ponto, esses Blocos L2 não têm finalidade e podem ser revertidos pelo sequenciador.

A cada poucos minutos, o sequenciador comprime os dados de transação sequenciados da L2, os agrega em lotes e os submete ao contrato SequencerInbox na Camada 1 para garantir a disponibilidade de dados e a operação do protocolo Rollup. Geralmente, os dados da L2 submetidos à Camada 1 não podem ser revertidos e podem ter finalidade.

A partir do processo acima, podemos resumir que a Camada 2 possui sua própria rede de nós, mas esses nós são poucos em número e geralmente carecem dos protocolos de consenso comumente usados em blockchains públicos. Portanto, sua segurança é fraca e eles devem depender do Ethereum para garantir a confiabilidade da publicação de dados e a validade das transições de estado.

Protocolo de Rollup Arbitrum:

Define a estrutura de blocos, chamados RBlocks, na cadeia Rollup, a continuação da cadeia, a publicação de RBlocks e o processo do modo de desafio, etc., por meio de uma série de contratos. É importante notar que a cadeia Rollup mencionada aqui não é o razão comummente entendido como Camada 2, mas sim uma estrutura de dados abstrata "semelhante a uma cadeia" estabelecida independentemente pela Arbitrum One para implementar mecanismos de prova de fraude.

Um RBlock pode conter os resultados de vários blocos L2, e sua entidade de dados, RBlock, é armazenada em uma série de contratos dentro do RollupCore. Se houver um problema com um RBlock, os validadores irão desafiá-lo com base em envios do criador do RBlock.

Validadores:

Validadores no Arbitrum são na verdade um subconjunto especial de nós completos da Camada 2, atualmente com admissão na lista branca.

Os validadores criam novos RBlocks (blocos Rollup, também chamados de assertivas) com base em lotes de transações enviadas ao contrato SequencerInbox pelo sequenciador, e monitoram o estado atual da cadeia Rollup para desafiar dados incorretos enviados pelo sequenciador.

Os validadores ativos precisam apostar ativos na cadeia Ethereum com antecedência e são às vezes referidos como apostadores. Embora os nós da Camada 2 que não apostam ativos possam monitorar a operação do Rollup e enviar alertas aos usuários sobre anomalias, eles não podem intervir diretamente em dados incorretos enviados pelo sequenciador na cadeia Ethereum.

Desafio:

Os passos básicos podem ser resumidos como subdivisão interativa de várias rodadas e prova de um único passo. Na fase de subdivisão, ambos os desafiantes primeiro se envolvem em subdivisão interativa de várias rodadas dos dados da transação problemática até que a instrução de opcode problemática seja decomposta e verificada. O paradigma de "subdivisão de várias rodadas-prova de um único passo" é considerado pelos desenvolvedores da Arbitrum como a implementação mais eficiente em termos de gás de prova de fraude. Todos os passos são controlados por contratos inteligentes, e nenhuma das partes pode trapacear.

Período do Desafio:

Devido à natureza otimista da OP Rollup, após cada RBlock ser submetido à cadeia, o contrato não verifica ativamente, deixando um período de tempo para os validadores falsificarem. Esta janela de tempo é o período de desafio, que é de uma semana na mainnet Arbitrum One. Após o término do período de desafio, o RBlock será finalmente confirmado, e as mensagens correspondentes às transações de L2 para L1 (como operações de saque executadas através da ponte oficial) podem ser liberadas.

ArbOS, Geth, WAVM:

Arbitrum usa uma máquina virtual chamada AVM, que consiste em Geth e ArbOS. Geth é o software cliente mais comumente usado para Ethereum, e Arbitrum fez modificações leves para ele. O ArbOS é responsável por todas as funções especiais relacionadas ao L2, como gerenciamento de recursos de rede, geração de blocos L2 e trabalho em coordenação com o EVM. Consideramos a combinação de ambos como um AVM nativo, que é a máquina virtual usada pela Arbitrum. O WAVM é o resultado da compilação do código AVM no Wasm. No processo de contestação do Arbitrum, a "prova de etapa única" final verifica as instruções do WAVM.

Aqui, podemos representar as relações e fluxos de trabalho entre os vários componentes usando o diagrama abaixo:

Ciclo de Vida da Transação L2

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

1. O usuário envia instruções de transação ao sequenciador.
2. O sequenciador primeiro verifica os dados, incluindo assinaturas digitais, das transações a serem processadas, filtra transações inválidas e, em seguida, as sequencia e as calcula.
3. O sequenciador envia o recibo da transação para o usuário (geralmente muito rapidamente), mas isso é apenas o "pré-processamento" feito pelo sequenciador na cadeia Ethereum, e está em um estado de Finalidade Suave e não é confiável. No entanto, para os usuários que confiam no sequenciador (a maioria dos usuários), eles podem assumir otimisticamente que a transação foi concluída e não será revertida.
4. O sequenciador encapsula os dados da transação pré-processados em um lote após altamente comprimi-los.
5. Em intervalos regulares (afetados por fatores como volume de dados e congestionamento do Ethereum), o sequenciador publica o Lote de transação no contrato da Caixa de Entrada do Sequencer em L1. Neste ponto, pode-se considerar que a transação tem Hard Finality.

Contrato de Caixa de Entrada do Sequenciador

O contrato recebe lotes de transações enviadas pelo sequenciador para garantir a disponibilidade de dados. Em profundidade, os dados do lote na Caixa de Entrada do Sequenciador registram completamente as informações de entrada da transação da Camada2. Mesmo que o sequenciador falhe permanentemente, qualquer pessoa pode restaurar o estado atual da Camada2 com base nos registros do lote e assumir o sequenciador falhado/faltante.

Em uma analogia física, o que vemos como L2 é apenas a projeção do lote na Caixa de Entrada do Sequenciador, enquanto a fonte de luz é o Soft Finality. Como a fonte de luz Soft Finality não muda facilmente, a forma da sombra é determinada apenas pelo lote agindo como o objeto.

O contrato Sequencer Inbox também é chamado de caixa rápida, e o sequencer especificamente submete transações pré-processadas a ele, e apenas o sequencer pode submeter dados a ele. A caixa lenta correspondente é a Delayer Inbox, cuja função será descrita no processo subsequente.

Os validadores irão monitorar continuamente o contrato da Caixa de Entrada do Sequenciador. Sempre que o sequenciador publicar um Lote neste contrato, um evento on-chain é acionado. Ao detectar este evento, o validador irá baixar os dados do lote, executá-lo localmente e, em seguida, publicar um RBlock no contrato do protocolo Rollup na cadeia Ethereum.

O contrato da ponte Arbitrum tem um parâmetro chamado o acumulador, que registra informações sobre o novo lote L2 submetido e o número de transações recebidas na caixa de entrada lenta, entre outras coisas.

(O sequenciador envia continuamente lotes 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 é exibida completamente.)

O contrato SequencerInbox tem duas funções principais:

adicionar Sequenciador L2Batch From Origin()，O sequenciador chamará esta função sempre que enviar dados em lote para o contrato Sequenciador Inox.

Inclusão de força()，Esta função pode ser chamada por qualquer pessoa e é usada para implementar transações à prova de censura. A maneira como essa função entra em vigor será explicada em detalhes mais tarde, quando falarmos sobre o contrato de Caixa de Entrada Adiada.

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

Preços de gás

Obviamente, as transações L2 não podem ser gratuitas, pois isso levará a ataques DoS. Além disso, existem custos operacionais para o próprio sequenciador L2 e haverá sobrecarga para enviar dados no L1. Quando um usuário inicia uma transação dentro da rede Layer 2, a estrutura da taxa de gás é a seguinte:

O custo da publicação de dados gerados pela ocupação de recursos da Camada 1 vem principalmente dos lotes enviados pelo sequenciador (cada lote contém transações de muitos usuários), e o custo é compartilhado entre os iniciadores de transações. O algoritmo de precificação para taxas de transação geradas pela publicação de dados é dinâmico. O sequenciador ajusta a precificação com base nas condições recentes de lucro e prejuízo, tamanho do lote e no preço atual do gás Ethereum.

O custo incorrido pelos usuários ao ocupar os recursos da Camada2 é determinado definindo um limite máximo no gás processado por segundo para garantir a operação estável do sistema (atualmente Arbitrum One é 7 milhões). Os preços de orientação do gás tanto para L1 quanto para L2 são rastreados e ajustados pelo ArbOS, e a fórmula não é detalhada aqui.

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 claramente sentir que as taxas de transação Rollup são muito mais baratas do que na mainnet do ETH.

Prova de fraude otimista

Olhando para o texto anterior, é evidente que a Camada2 (L2) é essencialmente apenas uma projeção dos lotes de entrada de transações enviados pelo sequenciador na Caixa de Entrada do Sequenciador:

Inputs de Transação -> Função de Transição de Estado (STF) -> Saídas de Estado

As entradas já estão determinadas, e o STF é imutável, então o resultado de saída também é determinado. A prova de fraude e o sistema de protocolo de Rollup de Arbitrum publicam o estado de saída, representado por um RBlock (também conhecido como uma asserção), para a Camada 1 e fornecem provas otimistas para isso.

Na L1, existem dados de entrada publicados pelo sequenciador e estados de saída publicados pelos validadores. Após uma cuidadosa consideração, é necessário publicar o estado da Camada 2 na cadeia? Porque as entradas já determinaram completamente as saídas, e os dados de entrada são publicamente visíveis, enviar os resultados de saída ou estado parece redundante. No entanto, essa ideia ignora o fato de que precisa haver um acerto de estados entre os sistemas L1 e L2. Isso é especialmente necessário para ações de saque da L2 para a L1, que exigem prova de estado.

Ao construir o Rollup, a ideia central é descarregar a maioria dos cálculos e armazenamento para L2 para evitar os altos custos de L1. Isso implica que L1 não conhece o estado de L2; ele apenas auxilia o sequenciador L2 na publicação dos dados de entrada para todas as transações, mas não é responsável pelo cálculo do estado de L2.

As ações de retirada envolvem essencialmente desbloquear os ativos correspondentes do contrato L1 com base nas mensagens entre cadeias fornecidas pela L2 e transferi-los para a conta do usuário na L1 ou concluir outras tarefas.

Neste ponto, o contrato Layer1 perguntará: qual é o seu estado na Layer2 e como você prova que realmente possui os ativos que está reivindicando transferir? Nesta fase, os usuários precisam fornecer Provas de Merkle correspondentes, etc.

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

Na chamada prova otimista, o contrato não verifica se o status de saída enviado para L1 está correto, mas acredita otimistamente que tudo é preciso. O sistema de prova otimista pressupõe que há pelo menos um Validador honesto a qualquer momento. Se ocorrer um estado incorreto, será desafiado por meio de uma prova de fraude.

A vantagem deste design é que não é necessário verificar ativamente cada RBlock emitido para L1 para evitar desperdício de gás. Na verdade, para OPR, é irreal verificar cada afirmação, pois cada Rblock 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 perde o significado da escalabilidade da Camada 2.

ZKR não enfrenta esse problema porque as Provas ZK têm concisão, exigindo apenas a validação de uma pequena prova sem a necessidade de realmente executar as muitas transações por trás da prova. Portanto, ZKR não opera de forma otimista; cada publicação de estado é acompanhada por verificação matemática por um contrato Verificador.

Embora as provas de fraude não possam atingir o alto nível de concisão das provas de conhecimento zero, Arbitrum emprega um processo interativo de 'subdivisão de várias rodadas - prova de um único passo', onde, no final, apenas um único opcode da máquina virtual precisa ser comprovado, resultando em custos relativamente mais baixos.

protocolo Rollup

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

O contrato principal do protocolo Rollup é RollupProxy.sol. Ao garantir que a estrutura de dados seja consistente, é utilizada uma estrutura de agente duplo rara. 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 do L2BEAT)

No RollupProxy, uma série de RBlocks (também conhecidos como assertivas) enviados por diferentes validadores são registrados, representados por blocos no diagrama: verde para confirmado, azul para não confirmado e amarelo para refutado.

O RBlock contém o estado final resultante da execução de um ou mais blocos L2 desde o RBlock anterior. Esses RBlocks formam uma Cadeia Rollup em aparência (observe a distinção do próprio ledger L2). Em um cenário otimista, esta Cadeia Rollup não deve ter forks, pois o fork implica em validadores enviando Blocos Rollup conflitantes.

Para propor ou concordar com uma afirmação, os validadores precisam apostar uma certa quantidade de ETH, tornando-se um Validador. Isso garante a base econômica para o comportamento honesto entre os validadores, pois a aposta do perdedor será confiscada em caso de desafio/prova de fraude.

O bloco azul numerado 111 no canto inferior direito do diagrama será eventualmente refutado porque o bloco pai, número 104, está incorreto (amarelo).

Além disso, o Validador A propôs o Bloco Rollup 106, com o qual o Validador B discorda e desafia.

Após B iniciar o desafio, o contrato ChallengeManager é 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 Rollup, e a outra parte aponta qual parte do fragmento de dados está problemática. Um processo semelhante à dicotomia (na verdade, N/K) que estreita continuamente e gradualmente o escopo.

2. Posteriormente, pode-se identificar ainda mais qual transação e seus resultados são problemáticos, sendo então subdivididos para a instrução específica da máquina dentro dessa transação que está em disputa.

3. O contrato ChallengeManager apenas verifica se o segmento de "dados" gerado após subdividir os dados originais é válido.

4. Quando o desafiante e a parte desafiada identificam a instrução da máquina a ser desafiada, o desafiante invoca oneStepProveExecution() para enviar uma prova de fraude de um único passo, demonstrando que o resultado da execução desta instrução da máquina está incorreto.

Prova de um passo

A prova de um único passo é o cerne de toda a prova de fraude do Arbitrum. Vamos dar uma olhada em o que a prova de um único passo especificamente prova.

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

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

O cliente de nó da Arbitrum (sequenciador, validador, 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, você obterá o WAVM usado pelo verificador ao gerar provas de fraude, e o contrato para verificar a prova de um único passo também simula as funções da máquina virtual WAVM.

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

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

Após as rodadas anteriores de subdivisões interativas, a prova de um único passo finalmente provou a instrução de um único passo no conjunto de instruções do 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 comprovada e, em seguida, chama o verificador correspondente, como Mem, Math, etc., para passar a instrução de um único passo para o contrato verificador.

O resultado final após o Hash será retornado ao ChallengeManager. Se o hash for inconsistente com o hash após a operação de instrução registrada no Bloco Rollup, o desafio é bem-sucedido. Se forem consistentes, significa que não há problema com o resultado de execução deste comando registrado no Bloco Rollup, e o desafio falhou.

Aviso legal:

1. Este artigo é reimpresso de [Geek Web3], Todos os direitos autorais pertencem ao autor original [Luo Benben, ex-embaixador técnico da Arbitrum, colaborador geek web3]. Se houver objeções a este reenvio, entre em contato com o Gate Learnequipe e eles lidarão com isso prontamente.
2. Responsabilidade Legal: As visões e opiniões expressas 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 Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.