Como há uma falta de interpretação profissional de artigos ou materiais relacionados com 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 o máximo possível, ainda excede as 10.000 palavras. Portanto, está dividido em duas partes e recomenda-se que seja guardado e partilhado como material de referência.”

Visão geral do Rollup Sequencer

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

Optimização de custos: Transfira a maioria das tarefas de computação e armazenamento para a Camada 2, que é operada sob L1. O L2 funciona principalmente num único servidor, referido como sequenciador/operador, formando uma cadeia separada.

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

(Fonte: BNB Chain)

Garantia de segurança: O conteúdo da transação e o estado pós-transação no L2 são sincronizados com o Ethereum L1, e a sua validade é verificada através de contratos de transição de estado. Ao mesmo tempo, o Ethereum mantém a história do L2, portanto, mesmo se o sequenciador travar permanentemente, outros podem reconstruir todo o estado de L2 através de registos Ethereum.

Fundamentalmente, a segurança do Rollup depende do Ethereum. Se o sequenciador não souber a chave privada de uma conta, não pode iniciar transações em nome dessa conta ou manipular o saldo de ativos da conta (mesmo se tentado, seria rapidamente detectado).

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

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

Os mecanismos de verificação do estado para prevenir ações maliciosas por sequenciadores Rollup estão divididos em duas categorias: Prova de Fraude e Prova de Validade. As soluções de rollup que utilizam a Prova de Fraude são referidas como OP Rollup (Optimistic Rollup, OPR), enquanto as que utilizam a Prova de Validação são frequentemente chamadas de ZK Rollup (Zero-Knowledge Proof Rollup, ZKR) em vez de Validad Rollup devido à bagagem histórica.

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

Portanto, o OPR implica uma suposição de confiança: a qualquer momento, há pelo menos um nó validador L2 honesto. Por outro lado, os contratos ZKR validam de forma ativa e barata os dados apresentados pelo sequenciador através de cálculos criptográficos.

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

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

Este artigo fornece uma introdução aprofundada ao projeto líder no Optimistic Rollup — Arbitrum One, cobrindo todos os aspetos de todo o sistema. Depois de ler com atenção, terá uma compreensão profunda do Arbitrum e Optimistic Rollup/OPR.

Componentes principais e fluxo de trabalho do Arbitrum

Contratos principais:

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

Sequenciador:

O sequenciador recebe transações do utilizador, classifica-as, calcula os resultados da transação e rapidamente (normalmente < 1s) devolve recibos aos utilizadores. Os utilizadores vêem frequentemente as suas transações no L2 dentro de alguns segundos, proporcionando uma experiência semelhante às plataformas Web2.

Simultaneamente, o sequenciador transmite imediatamente o último bloco L2 gerado sob a cadeia Ethereum fora da cadeia. Qualquer nó da Camada 2 pode receber de forma assíncrona estes Blocos L2. No entanto, estes blocos L2 não têm finalidade neste momento e podem ser revertidas pelo sequenciador.

A cada poucos minutos, o sequenciador comprime os dados ordenados da transação L2, agrega-os em lotes e envia-os ao contrato SequenceInbox na Camada1 para garantir a disponibilidade dos dados e a operação do protocolo Rollup. Geralmente, os dados L2 submetidos à Camada1 não podem ser revertidos e podem ter determinismo final.

A partir do processo acima podemos resumir: A Camada 2 tem a sua própria rede de nós, mas o número destes 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 depender do Ethereum para garantir a fiabilidade da divulgação de dados e a eficácia das transições de estado. sexo.

Protocolo de Rollup Arbitrum:

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. Note que a cadeia Rollup mencionada aqui não é o livro-razão da Camada 2 que todos compreendem, mas uma “estrutura de dados em cadeia” abstrata configurada independentemente pelo Arbitrum One para implementar o mecanismo de prova de fraude.

Um rBlock pode conter os resultados de vários blocos L2 e os dados também são muito diferentes. A sua entidade de dados rBlock está armazenada numa série de contratos no RollupCore. Se houver um 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 branca.

O
Validator cria um novo RBlock (bloco de rollup, também chamado de asserção) com base no lote de transações submetido pelo sequenciador ao contrato SequencerInbox, bem como monitoriza o estado da cadeia de rollup atual e contesta os dados incorretos enviados pelo sequenciador.

O Active Validator precisa de ter ativos na cadeia ETH antecipadamente. Às vezes também chamamos-lhe Staker. Embora os nós da Camada 2 que não estão em jogo também possam monitorizar a dinâmica de operação do Rollup e enviar alarmes anormais aos utilizadores, eles não podem intervir diretamente nos dados de erro apresentados pelo sequenciador na cadeia ETH.

Desafio:

As etapas básicas podem ser resumidas como várias rodadas de segmentação interativa e prova de uma etapa. No processo de segmentação, as partes desafiadoras primeiro conduzem várias rodadas de segmentação nos dados problemáticos da transação até decompor as instruções do código de operação problemático e conduzem a verificação. O paradigma das “múltiplas rondas de segmentação - prova de uma etapa” é considerado pelos programadores do Arbitrum como a implementação mais economizadora de gás da prova de fraude. Todos os links estão sob controlo de contrato e nenhuma parte pode trapacear.

Período de desafio:

Devido à natureza otimista do OP Rollup, depois de cada RBlock ser submetido à cadeia, o contrato não verifica ativamente, deixando um período de janela para o verificador falsificar. Este período de janela é o período de desafio, que leva 1 semana na rede principal do Arbitrum One. Após o término do período de desafio, o rBlock será finalmente confirmado. Apenas 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.

Rabos, Geth, WAVM：

A máquina virtual usada pelo Arbitrum chama-se AVM, que inclui Geth e ARBOs. O Geth é o software cliente mais utilizado no Ethereum, e o Arbitrum fez modificações leves. O ARBos é responsável por todas as funções especiais relacionadas com o L2, tais como gestão de recursos de rede, geração de blocos L2, trabalho com EVM, etc. Consideramos a combinação dos dois como um AVM nativo, que é a máquina virtual usada pelo Arbitrum. O WAVM é o resultado da compilação do código AVM no WASM. No processo de desafio do Arbitrum, a última “prova de uma etapa” verifica a instrução WAVM.

Aqui, podemos usar a figura a seguir para representar a relação 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 utilizadores enviam instruções de negociação para o sequenciador.

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

3. O sequenciador envia o recibo da transação ao utilizador (normalmente muito rápido), que é apenas o “pré-processamento” realizado pelo classiador sob a cadeia ETH. Está no estado de Soft Finality e não é fiável. Mas para os utilizadores (a maioria dos utilizadores) que confiam no sequenciador, podem estar otimistas de que a transação foi concluída e não será revertido.

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

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

Contrato de caixa de entrada do sequenciador

O contrato receberá o lote de transações submetido pelo sequenciador para garantir a disponibilidade dos dados. Se olharmos para isto de uma forma mais profunda, os dados do lote na Caixa de Entrada do Sequenciador registam completamente as informações de entrada da transação da Camada2. Mesmo que o sequenciador esteja permanentemente inactivo, qualquer pessoa pode restaurar o estado atual da Camada 2 com base no registo do lote e substituir o sequenciador defeituoso/em execução.

Para entendê-lo de uma forma física, o L2 que vemos é apenas a projeção do lote no SequencerInbox, e a fonte de luz é STF. Porque a fonte de luz STF não muda facilmente, a forma da sombra é determinada apenas pelo lote que age como o objeto.

O contrato da Caixa de Entrada do Sequencer chama-se caixa rápida. O sequenciador submete especificamente transações pré-processadas para ele, e apenas o sequenciador pode enviar dados a ele. A caixa rápida correspondente é a caixa lenta Delayer Inbox, e a sua função será descrita no processo subsequente.

O Validator monitorizará sempre o contrato da Caixa de Entrada do Sequenciador. Sempre que o sequenciador libera um lote para o contrato, será produzido um evento on-chain. Depois que o Validador detectar a ocorrência deste evento, irá descarregar os dados do lote. Após a execução local, o RBlock será emitido para o contrato do protocolo Rollup na cadeia ETH.

O contrato de ponte do Arbitrum tem um parâmetro chamado acumulador, que registra o lote L2 recém-enviado, bem como o número e a informação de transações recém-recebidas na lenta Caixa de entrada.

（O sequenciador submete continuamente lotes para a Caixa de Entrada do Sequenciador)

（A informação específica do Lote; o campo de dados corresponde aos dados do lote. O tamanho desta parte dos dados é muito grande e a captura de ecrã não é totalmente apresentada.

O contrato SequenciInbox tem duas funções principais:

adicionar Sequenciador L2Batch From Origin ()

O sequenciador chamará esta função todas as vezes para enviar dados de lote para o contrato 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 pormenor mais tarde, quando falarmos sobre o contrato da Caixa de Entrada Atrasada.

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á despesas gerais para o envio de dados no L1. Quando um utilizador inicia uma transação dentro da rede da Camada 2, a estrutura da taxa de gás seria a seguinte:

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

Este custo vem principalmente dos lotes enviados pelo sequenciador (cada lote tem muitas transações do utilizador), e o custo é, em última análise, partilhado igualmente entre os iniciadores da transação. O algoritmo de preços de taxas gerado pela divulgação de dados é dinâmico e o sequenciador irá precificar com base no estado recente de lucros e perdas, tamanho do lote e preço atual do gás Ethereum.

O custo incorrido pelos utilizadores que ocupam recursos da Camada 2

É estabelecido um limite de gás para o TPS para garantir o funcionamento 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 pelos 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 utilizadores não precisam de estar cientes destes 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 optimista

Recordando o acima exposto, L2 é apenas a projeção do lote de entrada da transação apresentado pelo sequenciador na caixa rápida, ou seja:

Entradas de Transação - > STF - > Saídas de Estado. A entrada foi determinada e o STF permanece inalterado, então o resultado da saída também é determinado. 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 executa provas otimistas sobre ele.

No L1, há dados de entrada publicados pelo sequenciador e estado de saída publicado pelo verificador. Vamos considerar isso 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 publicamente visíveis, parece redundante enviar o estado do resultado de saída? Mas esta ideia ignora a necessidade real de acordo estatal 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 centrais é colocar a maior parte da computação e armazenamento no L2 para evitar o alto custo do L1. Isto significa que o L1 não sabe o estado do L2, só ajuda o 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 levantamento é essencialmente desbloquear os fundos correspondentes do contrato L1, transferi-lo para a conta L1 do utilizador ou completar outras coisas seguindo a mensagem de cadeia cruzada dada pela L2.

Neste momento, o contrato da Camada 1 perguntará: Qual é o seu estatuto na Camada 2 e como provar que realmente possui os ativos que declara serem transferidos? Neste momento, o utilizador deve fornecer o Merkle Proof correspondente, etc.

Portanto, se construirmos um Rollup sem uma 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 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 submetido a L1 está correto, mas acredita com otimismo que tudo é preciso. O sistema de prova otimista assume que há pelo menos um Validador honesto a qualquer momento. Se ocorrer um estado incorreto, será contestado através de provas de fraude.

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

O ZKR não tem este problema, porque o ZK Proof é conciso. Só precisa de verificar uma prova muito pequena, e não há necessidade de realmente executar muitas transações correspondentes à Prova. Portanto, o ZKR não opera de forma otimista. Sempre que o estado for divulgado, haverá um contrato de Verificador para verificação matemática.

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

Protocolo de 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 é RollupProxy.sol, que utiliza uma estrutura rara de agente duplo enquanto garante 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 o Scan.

Além disso, o contrato ChallengeManager.sol é responsável pela gestão dos desafios, e os contratos da série OneStepProver são utilizados para determinar provas de fraude.

(Fonte: site oficial L2BEAT)

Isto mostra a gravação de uma série de RBlocks (também conhecido como asserções), em RollupProxy, apresentados por diferentes Validadores, que são as caixas na 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. Estes RBlocks formam uma cadeia de rollup formal (note que o livro-razão L2 em si é diferente). Em circunstâncias otimistas, esta cadeia de rollup não deve ter bifurcações, porque uma bifurcação significa que um Validador apresentou blocos de rollup conflitantes.

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

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

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

Depois de 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 num determinado bloco de 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 âmbito.

2. Depois disso, pode continuar a localizar a transação e o resultado que são problemáticos e, em seguida, subdividi-la ainda mais em uma instrução de máquina disputada na transação.

3. O contrato ChallenManager verifica apenas 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 da máquina que será contestada, o desafiante chama a função 'OneStepProExecution () '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 de um passo

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

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

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

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

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

Então, porque é que precisa de ser compilado no bytecode Wasm ao gerar provas de fraude? A principal razão é que, para verificar o contrato de 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 a simulação no contrato.

No entanto, o WASM é um pouco mais lento 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 segmentações interativas, a prova de uma etapa 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 qual categoria o código de operação da instrução a ser provada pertence e, em seguida, chama o provador correspondente, como Mem, Matemática, etc., para passar a instrução de uma etapa para o contrato de comprovação.

O resultado final AfterHash será devolvido ao Challenge Manager. Se o hash for inconsistente com o hash após a operação de instrução registada no bloco de rollup, o desafio é bem-sucedido. Se forem consistentes, significa que não há problema com o resultado da execução desta instrução registada no bloco de rollup, e o desafio falhou.

Na parte 2, analisaremos o Arbitrum e até mesmo o módulo de contrato que lida com as funções de mensagens/ponte entre cadeias cruzadas/entre a Camada2 e a Camada1, e esclarecer ainda mais como uma verdadeira Camada2 deve atingir resistência à censura.

Isenção de responsabilidade：

1. Este artigo foi reimpresso do [WeChat]. Todos os direitos de autor pertencem ao autor original [Luo Benben]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.