Este artigo é a interpretação técnica do Arbitrum One por Luo Benben, ex-embaixador técnico da Arbitrum e ex-cofundador da empresa de auditoria de automação de contratos inteligentes Goplus Security.
Escrito por: Luo Benben, ex-embaixador técnico da Arbitrum e contribuidor geek web3
**Este artigo é a interpretação técnica do Arbitrum One por Luo Benben, ex-embaixador técnico da Arbitrum e ex-cofundador da empresa de auditoria de automação de contratos inteligentes Goplus Security. **
Como há uma falta de interpretação profissional do Arbitrum e até mesmo do OP Rollup nos artigos ou materiais relacionados à Camada 2 no círculo chinês, este artigo tenta preencher a lacuna neste campo, popularizando o mecanismo operacional do Arbitrum. Como a estrutura do Arbitrum em si é muito complexa, o texto completo ainda ultrapassa 10.000 palavras, embora seja o mais simplificado possível, por isso está dividido em duas partes. Recomenda-se coletá-lo e encaminhá-lo como referência! **
Breve descrição do classificador de rollup
O princípio da expansão Rollup pode ser resumido em dois pontos:
**Otimização de custos: Transfira a maioria das tarefas de computação e armazenamento para a cadeia L1, ou seja, L2. **L2 é principalmente uma cadeia executada em um único servidor, ou seja, o sequenciador/operador.
O classificador parece próximo a um servidor centralizado. Nos “três aspectos impossíveis do blockchain”, a “descentralização” é abandonada em troca de TPS e vantagens de custo. Os usuários podem permitir que L2 processe instruções de transação em vez de Ethereum, e o custo é muito menor do que negociar no Ethereum.
(Fonte: Rede BNB)
Garantia de Segurança: **O conteúdo da transação e o status pós-transação no L2 serão sincronizados com o Ethereum L1, e a validade da transição de status será verificada através do contrato. **Ao mesmo tempo, os registros históricos de L2 serão mantidos no Ethereum. Mesmo que o sequenciador esteja permanentemente inativo, outros podem restaurar todo o estado L2 por meio dos registros no Ethereum.
**Fundamentalmente, a segurança do Rollup é baseada no Ethereum. **Se o sequenciador não conhecer a chave privada de uma conta, ele não poderá iniciar transações em nome da conta, ou não poderá alterar o saldo de ativos da conta (mesmo que conheça, será rapidamente descoberto).
Embora o classificador seja centralizado como o hub do sistema,** na solução Rollup relativamente madura, o classificador centralizado só pode implementar comportamentos malignos leves, como revisão de transação ou tempo de inatividade malicioso,** mas em uma solução de rollup ideal, existem meios correspondentes para contenção (como mecanismos resistentes à censura, como retiradas forçadas ou triagem de provas).
(O protocolo Loopring define a função de retirada forçada no código-fonte do contrato em L1 para os usuários ligarem)
Os métodos de verificação de estado para evitar que o sequenciador Rollup faça o mal são divididos em duas categorias: Prova de Fraude e Prova de Validade. O esquema Rollup que usa prova de fraude é chamado de OP Rollup (Optimistic Rollup, OPR), enquanto devido a alguma bagagem histórica, o esquema Rollup que usa prova de validade é frequentemente chamado de ZK Rollup** (Zero-knowledge Proof Rollup, ZKR) em vez de Validity Rollup .
Arbitrum One é um OPR típico. Ele implanta contratos em L1 e não verifica ativamente os dados enviados. É otimista de que não há problemas com os dados. Se os dados enviados estiverem incorretos, o nó verificador L2 iniciará ativamente um desafio.
Portanto, **OPR também implica uma suposição de confiança: existe pelo menos um nó verificador L2 honesto a qualquer momento. **O contrato da ZKR usa cálculos criptográficos para verificar de forma ativa, mas econômica, os dados enviados pelo sequenciador.
(Método de operação de rollup otimista)
(modo de operação ZK Rollup)
Este artigo fornecerá uma introdução aprofundada ao Arbitrum One, o projeto líder em rollup otimista, cobrindo todos os aspectos de todo o sistema. Depois de lê-lo com atenção, você terá uma compreensão profunda do Arbitrum e do rollup/OPR otimista.
Principais componentes e fluxo de trabalho do Arbitrum
Contrato Básico:
Os contratos mais importantes da Arbitrum incluem **SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, etc. **Detalhes serão introduzidos posteriormente.
Sequenciador:
Receba e classifique as transações do usuário, calcule os resultados da transação e retorne os recibos aos usuários rapidamente (geralmente <1s). Muitas vezes, os usuários podem ver suas transações listadas no L2 em poucos segundos, e a experiência é semelhante à da plataforma Web2.
Ao mesmo tempo, o sequenciador também transmitirá o último bloco L2 imediatamente sob a cadeia Ethereum, e qualquer nó da camada 2 poderá recebê-lo de forma assíncrona. Mas neste momento, esses blocos L2 não são finais e podem ser revertidos pelo sequenciador.
A cada poucos minutos, o sequenciador compactará os dados de transação L2 classificados, agregará-os em lotes e os enviará ao contrato de caixa de entrada SequencerInbox na Camada 1 para garantir a disponibilidade dos dados e a operação do protocolo Rollup. De modo geral, os dados L2 enviados à Camada 1 não podem ser revertidos e podem ser finais.
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, portanto a segurança é muito fraca e deve ser garantida confiando no Ethereum.Confiabilidade na liberação de dados e eficácia das transições de estado. **
Protocolo cumulativo de arbitragem:
Uma série de contratos que definem a estrutura do bloco RBlock da cadeia Rollup, o método de continuação da cadeia, a liberação do RBlock e o processo do modo 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 à lista de permissões.
O validador cria um novo RBlock (bloco Rollup, também chamado de asserção) com base no lote de transações enviado pelo sequenciador ao contrato SequencerInbox,** e monitora o status da cadeia Rollup atual e avalia as transações enviadas pelo sequenciador. Desafio com dados incorretos. **
O Validador ativo precisa penhorar ativos na cadeia ETH antecipadamente, às vezes também o chamamos de Staker. Embora os nós da Camada 2 que não fazem promessa também possam monitorar a dinâmica de execuçã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 única 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 “** prova de subdivisão multi-rodada e etapa única” é considerado pelos desenvolvedores do Arbitrum como a implementação de prova de fraude que mais economiza gás. **Todos os aspectos 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. **Esta janela de tempo é o período do desafio, que é de 1 semana na rede principal do Arbitrum One. Após o término do período de desafio, o RBlock será finalmente confirmado, e as mensagens correspondentes passadas de L2 para L1 no bloco ** (como operações de saque realizadas através da ponte oficial) poderão 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 de etapa única” 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 L2
O fluxo de processamento de uma transação L2 é o seguinte:
1. O usuário envia instruções de negociação ao sequenciador.
2. O classificador primeiro verifica as transações a serem processadas em assinaturas digitais e outros dados, elimina transações inválidas e realiza classificação e cálculos.
3. O sequenciador envia o recibo da transação ao usuário (geralmente muito rápido), ** mas este é apenas o “pré-processamento” realizado pelo sequenciador na cadeia ETH. Ele está no estado de Soft Finality e é não confiável. **. Mas para os usuários que confiam no sequenciador (a maioria dos usuários), eles podem estar otimistas de que a transação foi concluída e não será revertida.
4. O classificador 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. Olhando mais de perto, os dados do lote no SequencerInbox registram completamente as informações de entrada da transação da Camada 2. **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 falha/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 Sequencer Inbox também é 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, sua função será descrita no processo subsequente.
O Validador sempre monitorará o contrato do SequencerInbox. **Sempre que o sequenciador liberar um Batch para o contrato, um evento on-chain será lançado. Depois que o Validador ouvir a ocorrência deste evento, ele fará o download dos dados do lote e o executará localmente.Finalmente, emita RBlock para o contrato do protocolo Rollup na cadeia ETH.
Existe um parâmetro chamado acumulador no contrato ponte da Arbitrum, 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 o SequencerInbox)
*
(Informações específicas do lote, o campo de dados corresponde aos dados do lote, esta parte dos dados é muito grande e a captura de tela não é totalmente exibida)
O contrato SequencerInbox tem duas funções principais:
adicionar Sequencer L2Batch From Origin(), o sequenciador chamará esta função sempre para enviar dados do lote para o contrato do Sequencer Inox.
force 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 acumulador no contrato da ponte.
Preço do gás
Obviamente, as transações L2 não podem ser gratuitas, pois isso levará a ataques DoS. Além disso, há custos operacionais para o próprio classificador L2 e haverá sobrecarga para o envio de dados em L1. Quando os usuários iniciam transações dentro da rede Camada 2, a estrutura de taxas de gás é a seguinte:
O custo de publicação de dados incorrido pela ocupação de recursos da Camada 1 vem principalmente do lote enviado pelo classificador (cada lote tem muitas transações de usuário) e, em última análise, o custo é compartilhado igualmente pelos iniciadores da transação. O algoritmo de precificação de taxas gerado pela divulgação de dados é dinâmico, e o classificador 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 devido à ocupação de recursos da Camada 2 define um limite de gás que pode ser processado por segundo para garantir a operação estável do sistema (atualmente o Arbitrum One é de 7 milhões). Os preços de orientação do gás de L1 e L2 são rastreados e ajustados pela ArbOS, e as fórmulas não serão descritas 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 classificador na caixa rápida, ou seja:
Entradas de transação -> STF -> Saídas de estado. A entrada foi determinada e o STF permanece inalterado, portanto o resultado da saída também é determinado. **O sistema de prova de fraude e o protocolo Arbitrum Rollup publicam a raiz do estado de saída para L1 na forma de RBlock (também conhecido como asserção) e é um sistema de prova otimista. **
Em L1, existem dados de entrada publicados pelo sequenciador e status de saída publicados pelo verificador. Vamos considerar com atenção, é necessário publicar o status da Camada 2 na cadeia?
Como a entrada já determina completamente a saída e os dados de entrada são visíveis publicamente, o envio do resultado de saída - estado parece redundante? Mas esta ideia ignora a real necessidade de liquidação de estado entre os dois sistemas L1-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 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 seguir a mensagem cross-chain dada por L2, desbloquear os fundos correspondentes do contrato L1, transferi-los para a conta L1 do usuário ou completar outras coisas. **
Neste momento, o contrato da Layer1 perguntará: **Qual é o seu status na Layer2 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 e acredita com otimismo que tudo está correto. **O sistema de prova otimista assumirá que há pelo menos um validador honesto a qualquer momento. Se ocorrer um estado incorreto, ele será contestado por meio de uma 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 Rblock contém um ou mais blocos L2, e cada transação precisa ser reexecutada em L1. Não é diferente de executar transações L2 diretamente em L1, que perde o significado da expansão da Camada 2.
ZKR não tem esse problema, porque a Prova ZK é simples e só precisa verificar uma Prova muito pequena. Não há necessidade de realmente executar muitas transações correspondentes à Prova. Portanto, o ZKR não opera de forma otimista, cada vez que o status for divulgado, haverá um contrato Verfier 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 “prova multi-rodada dividida em etapa única”. No final, o que precisa ser provado é apenas uma única máquina virtual código de operação, o custo é relativamente pequeno. **
Protocolo cumulativo
Vamos primeiro dar uma olhada em como funciona o protocolo Rollup, que é o ponto de entrada para iniciar desafios e iniciar provas.
**O contrato principal do protocolo Rollup é RollupProxy.sol. **Sob a condição de garantir uma estrutura de dados consistente, uma rara estrutura de agente duplo é usada. Um agente corresponde a duas implementações de RollupUserLogic.sol e RollupAdminLogic.sol. Em ferramentas como Scan It ainda não pode ser bem analisado.
Há também o contrato **ChallengeManager.sol responsável por gerenciar desafios, e a série de contratos OneStepProver para determinar provas de fraude. **
(Fonte da foto: site oficial da L2BEAT)
No RollupProxy são registradas uma série de RBlocks (também conhecidos como assertions) 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. Desta forma, quando ocorrer uma contestação/comprovação de fraude, a garantia do perdedor será perdida, sendo esta a base económica para garantir o comportamento honesto do verificador.
O bloco azul nº 111 no canto inferior direito da figura será eventualmente falsificado porque seu bloco pai nº 104 está errado (amarelo).
**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 é responsável por verificar o detalhamento das etapas do desafio:
-
A segmentação é um processo em que ambas as partes se revezam na interação: uma parte segmenta os dados históricos contidos em um determinado bloco rollup e a outra parte aponta qual parte do fragmento de dados é problemática. Um processo semelhante à dicotomia (na verdade N/K) que estreita contínua e gradualmente o escopo.
-
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.
-
O contrato ChallengeManager apenas verifica se os “fragmentos de dados” gerados após a segmentação dos dados originais são válidos.
-
Depois que o desafiante e o desafiado localizarem a instrução de máquina a ser desafiada, o desafiante chama oneStepProveution() e envia uma prova de fraude de etapa única para provar que há um problema com o resultado da execução desta instrução de máquina. **
Prova em etapa única
A prova de etapa única é o núcleo da prova de fraude da Arbitrum. Vamos dar uma olhada no que a prova de etapa única prova especificamente.
Isso requer primeiro a compreensão do WAVM, **Wasm Arbitrum Virtual Machine, que é uma máquina virtual compilada pelo módulo ArbOS e pelo módulo principal Geth (cliente Ethereum). **Como L2 é completamente diferente de L1, o núcleo Geth original deve ser ligeiramente modificado e funcionar com ArbOS.
Portanto, a transição de estado em L2 é na verdade um trabalho conjunto do ArbOS+Geth Core.
O cliente do 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, obterá o WAVM usado pelo verificador ao gerar as 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 ele precisa ser compilado no bytecode Wasm ao gerar provas de fraude? **O principal motivo é que para verificar o contrato à prova de fraude em uma única etapa, é necessário usar o contrato inteligente Ethereum para simular uma máquina virtual VM que pode processar um determinado conjunto de conjuntos de instruções, e WASM é fácil de implementar simulação no 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 subdivisões interativas, a prova de etapa única finalmente prova a instrução de etapa única no conjunto de instruções WAVM. **
Como pode ser visto no código abaixo, OneStepProofEntry deve primeiro determinar a qual categoria pertence o código de operação da instrução a ser provada e, em seguida, chamar o provador correspondente, como Mem, Math, etc., para passar a instrução de etapa única 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 deste comando registrado no Rollup Block e o desafio falhou.
No próximo artigo, analisaremos o Arbitrum e até mesmo o módulo de contrato que lida com mensagens cross-chain/funções de ponte entre a Camada2 e a Camada1, e esclareceremos ainda mais como uma verdadeira Camada2 deve alcançar resistência à censura.
