Encaminhar o Título Original：

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

Devido à falta de interpretação profissional do Arbitrum e até mesmo do OP Rollup em artigos ou materiais em chinês relacionados à Camada 2, este artigo tenta preencher a lacuna neste campo popularizando o mecanismo de funcionamento do Arbitrum. Como a estrutura do Arbitrum em si é muito complexa, embora o texto completo tenha sido simplificado o máximo possível, ainda excede 10.000 palavras, por isso está dividido em duas partes. Recomenda-se recolher e reencaminhar como referência!

Introdução breve ao sequenciador Rollup

O princípio da expansão do 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 em execução num único servidor, ou seja, o sequenciador/operator.

O sequenciador está próximo de um servidor centralizado em certo sentido. Na "trindade impossível do blockchain", a "descentralização" é abandonada em troca de TPS e vantagens de custo. Os usuários podem deixar L2 processar instruções de transação em vez de Ethereum, e o custo é muito menor do que negociar em 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 de L2, portanto, mesmo que o sequenciador trave permanentemente, outros podem reconstruir todo o estado de L2 a partir dos registros no Ethereum.

Fundamentalmente, a segurança do Rollup baseia-se no Ethereum. Se um sequenciador não conhecer a chave privada de uma conta, não poderá iniciar transações em nome dessa conta ou manipular o saldo de ativos dessa conta (mesmo que tente, seria rapidamente detetado).

Embora o sequenciador, como o centro do sistema, possa ter um tom centralizado, em soluções Rollup maduras, um sequenciador centralizado só pode se envolver em comportamentos maliciosos suaves, como censura de transações ou crashes maliciosos. No entanto, em soluções Rollup ideais, existem medidas correspondentes para restringir tais comportamentos (como saques forçados 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 os utilizadores chamarem)

Para prevenir 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 usam Prova de Fraude são chamadas de Rollup Otimista (OPR), enquanto aquelas que usam Prova de Validade são frequentemente referidas como Rollup ZK (Rollup de Prova de Conhecimento Zero, ZKR), em vez de Rollup de Validade, devido a questões históricas.

O Arbitrum One é um OPR típico, implantado em contratos L1, que não validam ativamente os dados enviados, mas assumem com otimismo 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 através 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, abrangendo todos os aspectos do sistema. Após uma leitura cuidadosa, você ganhará uma compreensão profunda de Arbitrum e 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, Outbox, RollupCore, Bridge, etc. Estes serão detalhados mais tarde.

Sequenciador:

Recebe transações de usuários e as sequencia, calcula os resultados das transações e retorna rapidamente (normalmente <1s) 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 L2 sequenciados, 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 L2 submetidos à Camada 1 não podem ser revertidos e podem ter finalidade.

A partir do processo acima, podemos resumir que a Camada 2 tem 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úblicas. 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 de modo de desafio, etc., através de uma série de contratos. É importante notar que a cadeia Rollup mencionada aqui não é o livro-razão comumente 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 nas submissões do criador do RBlock.

Validadores:

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

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

Os validadores ativos precisam apostar ativos na cadeia Ethereum antecipadamente e são às vezes referidos como apostadores. Embora os nós da Camada 2 que não apostam ativos possam monitorizar a operação do Rollup e enviar alertas aos utilizadores sobre anomalias, não podem intervir diretamente em dados incorretos submetidos 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 se envolvem primeiro em subdivisão interativa de várias rodadas dos dados da transação problemática até que a instrução do opcode problemático 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 de Desafio:

Devido à natureza otimista do OP Rollup, após a submissão de cada RBlock à cadeia, o contrato não 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 levantamento executadas através da ponte oficial) podem ser libertadas.

ArbOS, Geth, WAVM:

O Arbitrum usa uma máquina virtual chamada AVM, que consiste em Geth e ArbOS. Geth é o software cliente mais comumente usado para Ethereum, e a Arbitrum fez modificações leves nele. 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. WAVM é o resultado da compilação do código AVM no Wasm. No processo de contestação do Arbitrum, a "prova de uma única etapa" 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 para o sequenciador.
2. O sequenciador verifica primeiro os dados, incluindo assinaturas digitais, das transações a serem processadas, filtra transações inválidas e depois as sequencia e as computa.
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á num 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 de forma otimista 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 depois de altamente comprimi-lo.
5. Em intervalos regulares (afetados por fatores como volume de dados e congestão do Ethereum), o sequenciador publica o lote de transações no contrato Sequencer Inbox na L1. Neste ponto, pode-se considerar que a transação possui uma Finalidade Definitiva.

Contrato da 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 registam completamente as informações de entrada das transações da Camada 2. Mesmo que o sequenciador falhe permanentemente, qualquer pessoa pode restaurar o estado atual da Camada 2 com base nos registros do lote e assumir o sequenciador falhado/em falta.

Numa analogia física, aquilo que vemos como L2 é apenas a projeção do lote na Caixa de Sequenciador, enquanto a fonte de luz é a Finalidade Suave. Como a fonte de luz Finalidade Suave não muda facilmente, a forma da sombra é determinada apenas pelo lote que atua como o objeto.

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

Os validadores irão monitorizar continuamente o contrato Sequencer Inbox. Sempre que o sequenciador publicar um lote neste contrato, é desencadeado um evento on-chain. Ao detetar este evento, o validador irá descarregar os dados do lote, executá-los localmente e, em seguida, publicar um RBlock no contrato do protocolo Rollup na cadeia Ethereum.

O contrato de ponte Arbitrum tem um parâmetro chamado o acumulador, que regista 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 é totalmente exibida.）

O contrato SequencerInbox tem duas funções principais:

Adicione Sequencer L2Batch From Origin()，O sequenciador chamará esta função sempre que submeter dados em lote ao contrato Sequencer Inox.

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

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

Preços do 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 de taxas de gás é a seguinte:

O custo da publicação de dados gerados pela ocupação de recursos da Camada1 advém principalmente dos lotes submetidos pelo sequenciador (cada lote contém transações de muitos utilizadores), sendo que o custo é partilhado, no final, entre os iniciadores das transações. O algoritmo de preços para as taxas de transação geradas pela publicação de dados é dinâmico. O sequenciador ajusta o preço com base nas condições recentes de lucro e perda, no tamanho do lote e no preço atual do gás da Ethereum.

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

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

Prova de fraude otimista

Olhando para o texto anterior, é aparente que a camada 2 (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, portanto o resultado de saída também está determinado. A prova de fraude e o sistema de protocolo de Rollup Arbitrum publicam o estado de saída, representado por um RBlock (também conhecido como uma asserção), na Camada1 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, esta ideia ignora o fato de que é necessário haver um ajuste de estados entre os sistemas L1 e L2. Isso é especialmente necessário para ações de levantamento da L2 para a L1, que exigem prova de estado.

Ao construir Rollup, a ideia principal é transferir a maioria dos cálculos e armazenamento para L2 para evitar os altos custos do L1. Isso implica que o L1 não conhece o estado do L2; 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 do L2.

As ações de levantamento envolvem essencialmente desbloquear os ativos correspondentes do contrato L1 com base nas mensagens intercadeia fornecidas pelo L2 e transferi-los para a conta L1 do usuário ou completar outras tarefas.

Neste ponto, o contrato Layer1 perguntará: qual é o seu estado no Layer2 e como você prova que realmente possui os ativos que está alegando 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 é necessário um sistema de prova de estado como a 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 estado de saída enviado para L1 está correto, mas acredita otimisticamente que tudo está preciso. O sistema de prova otimista pressupõe que existe pelo menos um Validador honesto a qualquer momento. Se ocorrer um estado incorreto, será contestado através de uma prova de fraude.

A vantagem deste design é que não é necessário verificar ativamente cada RBlock emitido para L1 para evitar o desperdício de gás. Na verdade, para OPR, não é realista verificar cada afirmação, porque 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 este problema porque as Provas ZK têm sucintez, exigindo apenas a validação de uma prova pequena sem a necessidade de executar realmente 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, em última análise, apenas um opcode de 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 iniciar provas, ou seja, como funciona o protocolo Rollup.

O contrato principal do protocolo Rollup é o RollupProxy.sol. Ao garantir que a estrutura de dados seja consistente, é usada uma estrutura rara de agente duplo. Um agente corresponde a duas implementações de RollupUserLogic.sol e RollupAdminLogic.sol, o que não pode ser bem analisado por ferramentas como o Scan.

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

(Fonte: site oficial da L2BEAT)

No RollupProxy, uma série de RBlocks (também conhecidos como afirmações) submetidos por diferentes validadores são registados, 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. Estes RBlocks formam uma Cadeia Rollup na aparência (note a distinção do próprio livro-razão L2). Num cenário otimista, esta Cadeia Rollup não deve ter forks, pois o fork implica que os validadores estão a enviar Blocos Rollup conflituosos.

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, já que a aposta do perdedor será confiscada em caso de desafio/prova de fraude.

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

Além disso, o Validador A propôs o Bloco Rollup 106, o que o Validador B discorda e contesta.

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 alternam para interagir. Uma parte segmenta os dados históricos contidos num determinado Bloco Rollup, e a outra parte aponta qual parte do fragmento de dados está problemática. Um processo semelhante à dicotomia (na realidade N/K) que estreita continuamente e gradualmente o âmbito.

2. Posteriormente, pode ser ainda mais apurado qual transação e seus resultados são problemáticos, depois subdivididos para a instrução de máquina específica 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á falho.

Prova de um passo

A prova de um único passo é o cerne de toda a prova de fraude do Arbitrum. Vamos ver o que a prova de um único passo prova especificamente.

Isto requer primeiro compreender o WAVM. Wasm Arbitrum Virtual Machine é uma máquina virtual compilada pelo módulo ArbOS e pelo módulo central Geth (cliente Ethereum). Uma vez que o L2 é muito diferente do L1, o núcleo original do Geth teve de ser ligeiramente modificado e trabalhar com o ArbOS.

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

O cliente de nó do 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, obterá o WAVM usado pelo verificador ao gerar provas de fraude, e o contrato para verificar a prova de etapa única 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 um único passo, é necessário usar o contrato inteligente Ethereum para simular uma máquina virtual (VM) que pode lidar com um certo conjunto de instruções, e WASM é fácil de implementar a simulação no contrato.

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

Após as rondas anteriores de subdivisões interativas, a prova de um passo finalmente provou a instrução de um passo no conjunto de instruções WAVM.

Como pode ser visto no código abaixo, OneStepProofEntry primeiro determina a que categoria pertence o código de operação da instrução a ser provada, e depois chama o respectivo provador, como Mem, Math, etc., para passar a instrução de um único passo para o contrato do provador.

O resultado final após o Hash será devolvido ao ChallengeManager. Se o hash for inconsistente com o hash após a operação de instrução registada no Bloco Rollup, o desafio é bem-sucedido. Se forem consistentes, significa que não há problema com o resultado de execução deste comando registado 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, contribuidor geek da web3]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa, e eles irão tratar dela prontamente.
2. Responsabilidade de Isenção de Responsabilidade: As 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. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.