Ex-Embaixador Técnico da Arbitrum Explica a Estrutura de Componentes da Arbitrum (Parte I)

Autor: Benben Luo, ex-embaixador técnico da Arbitrum e colaborador geek web3

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

Como os artigos ou materiais que envolvem a Camada 2 no círculo chinês carecem de uma interpretação profissional do Arbitrum e até mesmo do OP Rollup, este artigo tenta preencher a lacuna neste campo popularizando o mecanismo de operação do Arbitrum. Devido à complexidade da própria estrutura do Arbitrum, o texto completo ainda é de mais de 10.000 palavras com base na simplificação do máximo possível, por isso é dividido em dois artigos, que são recomendados para serem coletados e encaminhados como materiais de referência!**

Uma breve descrição do sequenciador Rollup

O princípio do rollup scaling pode ser resumido em dois pontos:

Otimização de custos: descarregue a maioria das tarefas de computação e armazenamento para L1 off-chain, ou seja, L2. **L2 é principalmente uma cadeia executada em um único servidor, ou seja, um sequenciador/operador.

O sequenciador parece próximo de um servidor centralizado, abandonando a “Descentralização” em “Blockchain Impossível Três Vezes” 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 a um custo muito menor do que negociar em Ethereum.

**Segurança: O conteúdo da transação em L2 e o estado após a transação serão sincronizados com Ethereum L1, e a validade da transição de estado será verificada através do contrato. Ao mesmo tempo, o histórico L2 será mantido no Ethereum e, mesmo que o sequenciador esteja permanentemente inativo, outros podem restaurar todo o estado L2 através dos registros no Ethereum.

Fundamentalmente, a segurança dos Rollups é baseada no Ethereum. Se o sequenciador não conhece a chave privada de uma conta, não pode iniciar transações em nome dessa conta, ou adulterar o saldo de ativos dessa conta (e mesmo que o faça, é rapidamente reconhecido).

Embora o sequenciador seja centralizado como a espinha dorsal do sistema, no esquema Rollup relativamente maduro, o sequenciador centralizado só pode implementar comportamentos maléficos suaves, como revisão de transações ou tempo de inatividade malicioso, mas no esquema Rollup ideal, existem meios correspondentes para coibi-lo (como mecanismos de resistência à censura, como retiradas forçadas ou provas de ordem).

Os métodos de verificação de estado para evitar que o sequenciador de rollup seja maligno são divididos em dois tipos: Prova de Fraude e Prova de Validade. Os rollups que usam provas de fraude são chamados de OP Rollups (Optimistic Rollups, OPRs) e, devido a alguma bagagem histórica, os Rollups que usam provas de validade são frequentemente chamados de ZK Rollups (Zero-knowledge Proof Rollups, ZKR) em vez de Validity Rollups.

O Arbitrum One é um OPR típico que implanta contratos em L1 e não valida ativamente os dados enviados, acreditando otimistamente que não há nenhum problema com os dados. Se houver um erro nos dados enviados, o nó validador de L2 inicia um desafio.

Portanto, OPR também implica uma suposição de confiança: há pelo menos um nó validador L2 honesto a qualquer momento. O contrato da ZKR, por outro lado, usa criptografia para verificar ativamente, mas de forma econômica, os dados enviados pelo sequenciador.

Neste artigo, apresentaremos o Arbitrum One, o projeto líder em rollups otimistas, cobrindo todos os aspetos de todo o sistema, e depois de ler com atenção, você terá uma compreensão profunda do Arbitrum e do rollup/OPR otimista.

Principais componentes e fluxos de trabalho da Arbitrum

Contratos principais:

Os contratos mais importantes da Arbitrum incluem SequencerInbox, DelayedInbox, L1 Gateways, L2 Gateways, Outbox, RollupCore, Bridge, etc. Mais sobre isso mais tarde.

Sequenciador:

As transações do usuário são recebidas e classificadas, os resultados das transações são calculados e um recibo é devolvido ao usuário rapidamente (geralmente < 1s). Os usuários muitas vezes podem ver suas transações na cadeia L2 em questão de segundos, assim como uma plataforma Web2.

Ao mesmo tempo, o sequenciador também transmitirá o mais recente Bloco L2 em tempo real sob a cadeia Ethereum, e qualquer Nó Layer2 pode recebê-lo de forma assíncrona. Mas neste ponto, esses blocos L2 não são finalizados e podem ser revertidos pelo sequenciador.

A cada poucos minutos, o sequenciador compactará os dados de transação L2 classificados, os agregará em lotes e os enviará para o contrato de caixa de entrada SequencerInbox na Camada 1 para garantir a disponibilidade dos dados e a operação do protocolo Rollup. Em geral, os dados L2 enviados para a Camada 1 não podem ser revertidos e podem ser finalizados.

A partir do processo acima, podemos resumir: Layer2 tem sua própria rede de nós, mas o número desses nós é escasso, e geralmente não há nenhum protocolo de consenso usado pela cadeia pública, então a segurança é muito pobre, e deve ser anexado ao Ethereum para garantir a confiabilidade da liberação de dados e a eficácia da transição de estado.

Protocolo de Rollup de Arbitrum:

Uma série de contratos que definem a estrutura do Bloco RBlock da cadeia Rollup, a continuação da cadeia, o lançamento do RBlock e o processo do modo desafio. Observe que a cadeia Rollup mencionada aqui não é um livro-razão Layer2 como o entendemos, mas uma “estrutura de dados em cadeia” abstrata criada pela Arbitrum One para implementar um mecanismo à prova de fraude.

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

Validador:

O Nó validador do Arbitrum é, na verdade, um subconjunto especial de Nós Completos da Camada 2, atualmente com acesso à Lista de Permissões.

O Validador cria um novo RBlock (Bloco de Rollup, também conhecido como asserção) com base no lote de transações enviadas pelo sequenciador para o contrato SequencerInbox e monitora o estado da cadeia atual do Rollup para contestar os dados errados enviados pelo sequenciador.

Os validadores ativos exigem a participação prévia de ativos na cadeia ETH, às vezes referidos como stakers. Embora os nós de camada 2 que não estão em estaca também possam monitorar a dinâmica de execução de rollups, enviar alarmes anormais aos usuários, etc., eles não podem intervir diretamente nos dados de erro enviados pelo sequenciador na cadeia ETH.

Desafio:

As etapas fundamentais podem ser resumidas como segmentação interativa multi-round e provas de etapa única. Na sessão de segmentação, ambas as partes são desafiadas a realizar várias rodadas de subdivisão baseada em turnos dos dados de transação problemáticos até que a instrução de código de operação da etapa problemática seja quebrada e verificada. O paradigma da “segmentação multi-round - single-step proof” é considerado pelos desenvolvedores da Arbitrum como a implementação mais eficiente de provas de fraude. Tudo está sob controle contratual e nenhuma das partes pode trapacear.

Período de Desafios:

Devido à natureza otimista do OP Rollup, após cada RBlock ser submetido à cadeia, o contrato não o verifica ativamente, deixando uma janela de tempo para os validadores falsificarem. Esta janela de tempo é o período de desafio, que é de 1 semana no Arbitrum One Mainnet. Após o término do período de desafio, o RBlock será finalizado, e a mensagem correspondente de L2 a L1 no bloco (como uma operação de retirada realizada através da ponte oficial) poderá ser liberada.

ArbOS, Geth, WAVM:

A máquina virtual usada pela Arbitrum é chamada AVM, que consiste em duas partes: Geth e ArbOS. Geth é o software cliente mais usado do 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, trabalho com o EVM, etc. Pensamos na combinação dos dois como um AVM nativo, que é a máquina virtual usada pela Arbitrum. WAVM é o resultado da compilação do código do AVM no Wasm. No processo de contestação do Arbitrum, a “prova em uma única etapa” final verifica as instruções do WAVM.

Aqui, podemos ilustrar a relação e o fluxo de trabalho entre os componentes acima no diagrama a seguir:

Ciclo de vida da transação L2

Veja como funciona uma transação L2:

1. O usuário envia uma instrução de negociação para o sequenciador.

2. O sequenciador primeiro verifica os dados, como a Assinatura Digital da transação a ser processada, elimina a transação inválida e classifica e calcula.

3. O sequenciador envia o recibo da transação para o usuário (geralmente muito rápido), mas este é apenas o “pré-processamento” do sequenciador fora da cadeia ETH, que está em um estado de Soft Finality e não é confiável. Mas para os usuários que confiam no sequenciador (a maioria dos usuários), é otimista que a transação foi concluída e não será revertida.

4. O sequenciador encapsula os dados brutos de transação pré-processados em um lote após alta compressão.

5. De vez em quando (afetado por fatores como volume de dados, congestionamento de ETH, etc.), o sequenciador publicará lotes de transações no contrato da Caixa de Entrada do Sequencer em L1. Neste ponto, a transação pode ser considerada como tendo um Hard Finality.

Contrato da Caixa de entrada do Sequencer

O contrato receberá o lote de transações enviado pelo sequenciador para garantir a disponibilidade dos dados. Olhando mais profundamente, os dados de lote no SequencerInbox registram completamente as informações de entrada de transação da Camada 2, mesmo que o sequenciador esteja permanentemente inativo, qualquer pessoa pode restaurar o estado atual da Camada 2 com base no registro em lote, substituindo o sequenciador de tração defeituoso/Rug.

Fisicamente, o que vemos como L2 é apenas uma 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 conhecido como Fastbox, é um sequenciador que envia 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 suas funções serão descritas no processo subsequente.

O Validador sempre ouvirá o contrato do SequencerInbox e, sempre que o sequenciador liberar um lote para o contrato, ele lançará um evento on-chain, e depois que o Validador ouvir esse evento, ele baixará os dados do lote e, após a execução local, liberará o RBlock para o contrato do protocolo Rollup na cadeia ETH.

O contrato ponte da Arbitrum tem um parâmetro chamado acumulador, que registrará o número de lotes L2 recém-enviados, bem como o número de transações recém-recebidas e informações na caixa de entrada lenta.

O contrato SequencerInbox tem duas funções principais:

adicionar Sequencer L2Batch From Origin(), que o sequenciador chama cada vez para enviar dados de lote para o contrato Sequencer Inox.

force Inclusion(), que pode ser chamado por qualquer pessoa e é usado para implementar transações resistentes à censura. Como essa função funciona será explicado com mais detalhes mais tarde, quando falarmos sobre o contrato de Caixa de entrada atrasada.

Ambas as funções chamam bridge.enqueueSequencerMessage() para atualizar o acumulador de parâmetros do acumulador no contrato de ponte.

Preço do gás

Obviamente, as transações L2 não podem ser gratuitas por causa de ataques DoS, os custos de execução do próprio sequenciador L2 e a sobrecarga de enviar dados em L1. Quando um usuário inicia uma transação dentro de uma rede de Camada 2, a taxa de gás é estruturada da seguinte forma:

O custo de publicação de dados gerado pela ocupação de recursos da Camada 1 vem principalmente dos lotes enviados pelo sequenciador (cada lote tem muitas transações de usuário), e o custo é, em última análise, compartilhado igualmente pelos iniciadores de transações. O algoritmo para a precificação de taxas geradas pela publicação de dados é dinâmico, e o sequenciador precifica com base no lucro e perda recentes, no tamanho do lote e no preço atual do gás Ethereum.

O custo incorrido pelos utilizadores devido à ocupação dos recursos da Camada 2 é fixado num número máximo de gases por segundo que pode garantir o funcionamento estável do sistema (atualmente 7 milhões para o 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 será repetida aqui por enquanto.

Embora o processo específico de cálculo do preço do gás seja mais complicado, os usuários não precisam perceber esses detalhes, e é óbvio que a Rollup Transaction Fee é muito mais barata do que a ETH Mainnet.

À prova de fraude otimista

Para recapitular, L2 é realmente apenas uma projeção da entrada em lote das transações enviadas pelo sequenciador no Fastbox, ou seja:

Entradas de transação -> STF -> State Outputs。 A entrada é determinada, o STF é constante, e a saída também é determinada, e o sistema de prova de fraude e o protocolo Arbitrum Rollup é um sistema que publica a raiz do estado da saída para L1 na forma de RBlock (também conhecido como asserção) e prova isso de forma otimista.

Em L1 há os dados de entrada publicados pelo sequenciador, e há também o estado de saída publicado pelo validador. Vamos dar uma olhada mais de perto, é necessário publicar o estado da Camada 2 on-chain?

Como a entrada determinou totalmente a saída, e os dados de entrada são publicamente visíveis, enviar o estado de saída - parece redundante, mas essa ideia ignora o fato de que a liquidação de estado é realmente necessária entre os sistemas L1-L2, ou seja, o comportamento proposto de L2 na direção de L1, e precisa haver prova de estado.

Ao construir um rollup, uma das ideias centrais é colocar a maior parte da computação e armazenamento em L2 para evitar o alto custo de L1, o que significa que L1 não sabe o estado de L2, apenas ajuda o sequenciador L2 a publicar os dados de entrada de todas as transações, mas não é responsável por calcular o estado de L2.

O comportamento de retirada é essencialmente desbloquear os fundos correspondentes do contrato L1 de acordo com a mensagem de interação entre cadeias dada por L2, transferi-los para a conta L1 do usuário ou completar outras coisas.

Neste ponto, o contrato da Camada 1 perguntará: qual é o seu estado na Camada 2 e como você pode provar que realmente possui os ativos que afirma cruzar. Neste momento, o usuário deve dar a prova Merkle correspondente, etc.

Assim, 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, na prática, isso é claramente inviável.

Na chamada prova otimista, o contrato não verifica se a saída submetida a L1 está no estado correto, e está otimista de que tudo está correto. O sistema de prova otimista pressupõe que há pelo menos um validador honesto a qualquer momento, e se houver um estado errado, ele é contestado por prova de fraude.

A vantagem deste design é que não há necessidade de validar ativamente cada RBlock publicado em L1 para evitar o desperdício de gás. Na verdade, não é prático para OPR verificar cada asserção, porque cada rblock contém um ou mais Bloco L2, e não é diferente de executar transações L2 diretamente em L1 para reexecutar cada transação em L1, o que perde o significado de escala de Camada 2.

ZKR não tem esse problema, porque ZK Proof tem simplicidade e só precisa verificar uma pequena prova, e não precisa realmente executar muitas transações por trás da prova. Portanto, a ZKR não está otimista, e toda vez que o estado de liberação é verificado matematicamente pelo contrato do Verificador.

Embora as provas de fraude não possam ser tão concisas quanto as Provas de Conhecimento Zero, a Arbitrum usa um processo de interação passo a passo “prova de divisão de várias rodadas” e, em última análise, apenas um único Código de Operação de máquina virtual precisa ser provado, o que é relativamente pequeno em custo.

Protocolo de Rollup

Vamos dar uma olhada em como o protocolo Rollup, o ponto de entrada para iniciar desafios e lançar provas, funciona.

O contrato principal do protocolo Rollup é RollupProxy.sol, que usa uma rara estrutura de proxy duplo para garantir a consistência da estrutura de dados, um proxy corresponde a duas implementações de RollupUserLogic.sol e RollupAdminLogic.sol, que não podem ser bem analisadas em ferramentas como Scan.

Além disso, há o contrato ChallengeManager.sol para gerenciar o desafio e a série de contratos OneStepProver para determinar provas de fraude.

No RollupProxy, uma série de RBlocks (também conhecidos como asserções) enviados por diferentes validadores são registrados, que são os quadrados no diagrama a seguir: verde - confirmado, azul - não confirmado, amarelo - falsificado.

RBlock contém o estado final de um ou mais blocos L2 após a execução desde o último RBlock. Estes RBlocks formam morfologicamente uma Cadeia de Rollup formal (note que o próprio livro-razão L2 é diferente). Em um cenário otimista, essa cadeia de rollup não deve ser bifurcada, porque ter uma bifurcação significa que há validadores que enviaram blocos de rollup conflitantes.

Para fazer ou concordar com uma afirmação, o validador precisa primeiro apostar uma certa quantidade de ETH para a asserção e se tornar um staker. Desta forma, no caso de uma impugnação/prova de fraude, a garantia do perdedor será cortada, que é a base económica para garantir o comportamento honesto dos validadores.

O bloco azul 111 no canto inferior direito da imagem acabará por ser falsificado porque o seu bloco pai 104 é Bloco errado (amarelo).

Além disso, o validador A propõe o Rollup Block 106, enquanto B discorda, desafiando-o.

Depois que B inicia um desafio, o contrato do ChallengeManager é responsável por validar o detalhamento das etapas do desafio:

1. A segmentação é um processo em que duas partes se revezam interagindo, com uma parte segmentando os dados históricos contidos em um bloco de rollup e a outra apontando qual parte do fragmento de dados é problemática. Semelhante a um processo de dicotomia (N/K, na verdade) que gradualmente estreita o intervalo.

2. Depois disso, você pode continuar a localizar qual transação e o resultado é problemático e, em seguida, subdividi-lo em uma instrução de máquina que é contestada nessa transação.

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

4. Quando o desafiante e a parte desafiada localizam a instrução da máquina a ser contestada, 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 da instrução da máquina.

Prova de uma etapa

As provas em uma única etapa estão no centro das provas de fraude em todo o Arbitrum. Vamos dar uma olhada no que uma prova de passo prova.

Isso requer uma compreensão do WAVM, Wasm Arbitrum Virtual Machine, que é uma máquina virtual compilada a partir de módulos ArbOS e módulos principais Geth (cliente Ethereum). Como L2 é muito diferente de L1 em muitos aspetos, o núcleo Geth original teve que ser levemente modificado e trabalhar com ArbOS.

Assim, as transições de estado em L2 são, na verdade, uma característica comum do ArbOS+Geth Core.

O Node Client da Arbitrum (Sequencer, Validator, Full Node, etc.) compila o programa processado pelo ArbOS+Geth Core acima em código de máquina nativo (para x86/ARM/PC/Mac/etc.) que pode ser processado diretamente pelo host do Node.

Se você alterar o idioma de destino compilado para Wasm, obterá o WAVM que o validador usa para gerar a prova de fraude, e o contrato que verifica a prova de etapa única também emulará a funcionalidade da máquina virtual WAVM.

A principal razão é que o contrato que verifica a prova de fraude de uma etapa usa o Contrato EthereumSmart para simular uma VM de máquina virtual que pode lidar com um determinado conjunto de conjuntos de instruções, e o WASM é fácil de implementar no contrato.

No entanto, o WASM é um pouco mais lento do que o código de máquina nativo, portanto, o WAVM só será usado pelo Nó/Contrato da Arbitrum quando as provas de fraude forem geradas e verificadas.

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

Como você pode ver no código a seguir, 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., e passa a instrução passo-a-passo para o contrato do provador.

O resultado final do afterHash retornará ao ChallengeManager e, se o hash for inconsistente com o hash registrado no Bloco de Rollup, o desafio será bem-sucedido. Se for consistente, significa que o resultado da execução da instrução gravada no Bloco de Rollup é bom e o desafio falha.

No próximo artigo, analisaremos os módulos de contrato que lidam com funções de interação/ponte entre cadeias cruzadas entre o Arbitrum e até mesmo a Camada 2 e a Camada 1, e esclareceremos melhor como uma verdadeira Camada 2 deve ser resistente à censura.