Ex-Embaixador Técnico da Arbitrum explica a estrutura de componentes da Arbitrum (Parte II)

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

No artigo anterior, “Former Arbitrum Technical Ambassadors Explain the Component Structure of Arbitrum (Part I)”, introduzimos o papel dos sequenciadores, validadores, contratos SequencerInbox, Rollup Blocks, e provas de fraude não interativas nos componentes principais do Arbitrum, e no artigo de hoje, vamos nos concentrar nos componentes dos componentes principais do Arbitrum relacionados a mensagens de interação entre cadeias e entradas de transações resistentes à censura.

Corpo: Em um artigo anterior, mencionamos que o contrato da Caixa de Entrada do Sequencer recebe especificamente o lote de pacotes de transação publicados pelo sequenciador na Camada 1. Ao mesmo tempo, destacamos que o Sequencer Inbox também é conhecido como Fast Box, em oposição ao Slow Box Delayed Inbox (Caixa de entrada). **Abaixo, examinaremos mais detalhadamente os componentes relacionados às mensagens de interação entre cadeias, como a Caixa de entrada atrasada.

Princípios de Interação entre Cadeias e Bridge

As operações de interação entre cadeias podem ser divididas em L1 a L2 (depósito) e L2 a L1 (levantamento). Observe que os depósitos e saques mencionados aqui não estão necessariamente relacionados à interação entre cadeias de ativos, e podem ser mensagens que não anexam ativos diretamente. Portanto, essas duas palavras significam apenas duas direções do comportamento relacionado à interação entre cadeias.

A transação Cross-Chain Interaction é mais complicada do que as transações L2 puras, as transações Cross-Chain Interaction têm informações trocadas em dois sistemas diferentes, L1 e L2.

Além disso, o que costumamos chamar de comportamento de interação entre cadeias é a interação entre cadeias em duas redes não relacionadas com uma ponte de interação entre cadeias em modo testemunha, e a segurança dessa interação entre cadeias depende do operador da ponte de interação entre cadeias, e o roubo de pontes de interação entre cadeias com base no modelo testemunha tem ocorrido com frequência na história.

O comportamento de Interação entre Cadeia entre o Rollup e o ETHMainnet é fundamentalmente diferente da Interação entre Cadeias acima, porque o estado da Camada 2 é determinado pelos dados registrados na Camada 1, desde que você use a ponte oficial de Interação entre Cadeias do Rollup, ela é absolutamente segura em termos de estrutura de operação. **

Isso também destaca a essência do Rollup, é apenas do ponto de vista do usuário, como uma cadeia independente, mas na verdade, a chamada ** “Layer2” é apenas uma janela de exibição rápida do Rollup aberta para os usuários, e sua estrutura de cadeia real ainda é queimada na Camada 1. Portanto, podemos pensar em L2 como meia cadeia, ou “uma cadeia criada na Camada 1”.

Bilhete retryable Retryables

Deve-se notar que a interação entre cadeias é assíncrona e não atômica, é impossível saber o resultado depois de concluir uma confirmação de transação como em uma cadeia, e não há garantia de que algo acontecerá do outro lado em um determinado momento. Portanto, a Interação entre Cadeias pode falhar devido a alguns problemas suaves, mas desde que os meios certos sejam usados, como o Ticket Retryable, problemas difíceis, como fundos bloqueados, não ocorrerão.

**Bilhetes retryable são as ferramentas básicas usadas ao depositar através da ponte oficial do Arbitrum, **Depósitos ETH e ERC20 são usados. O seu ciclo de vida divide-se em três fases:

**1. Envie o bilhete no L1. **Use o método createRetryableTicket() no contrato Caixa de entrada atrasada para criar um tíquete de depósito e enviá-lo.

**2. Resgate automático em L2. **Na maioria dos casos, o sequenciador pode resgatar automaticamente a fatura para o usuário, sem a necessidade de operação manual subsequente.

**3. L2. **Em alguns casos marginais, como um aumento repentino nos preços do gás em L2 e gás pré-pago insuficiente na nota, ele não será resgatado automaticamente. Neste caso, ele precisa ser feito manualmente pelo usuário.

Observe que, se o resgate automático falhar, você precisará resgatar manualmente a nota dentro de 7 dias, caso contrário, a conta será excluída (os fundos serão perdidos permanentemente), ou você precisará pagar uma taxa para renovar o contrato de locação para a preservação da conta.

Além disso, embora haja uma certa semelhança simétrica entre o processo de retirada da ponte oficial do Arbitrum e o comportamento do depósito, não há um conceito de Retryables, que pode ser entendido a partir do próprio protocolo Rollup, por um lado, e algumas diferenças, por outro:

Não há resgate automático no processo de retirada, porque não há temporizador ou automação no EVM, e o resgate automático pode ser realizado em L2, o que é conseguido com a ajuda do sequenciador, então os usuários em L1 precisam interagir manualmente com o contrato Outbox para recuperar ativos com Claim. Não há problema de contas vencidas para saques, desde que o período de contestação tenha passado, ele pode ser reivindicado a qualquer momento.

Gateway de interação entre cadeias de ativos ERC-20

• A interação entre cadeias de ativos do ERC-20 é complexa. Há algumas questões que podemos ponderar:
• Token implantado em L1, como é implantado em L2?
• Sua contraparte L2 precisa ser implantada manualmente com antecedência ou o sistema pode implantar automaticamente contratos de ativos para Tokens que cruzam, mas ainda não implantaram o contrato?
• Qual é o endereço contratual dos ativos do ERC-20 em L1 correspondente a L2? Deve ser coerente com L1?
• Como Cross-Chain Interaction para L1 para Tokens emitidos nativamente em L2?
• Tokens com funções especiais, como número ajustável de Rebase Tokens, Tokens de interesse auto-crescentes, como Cross-Chain Interaction?

Não vamos responder a todas essas perguntas, porque é muito complicado expandir. Estas perguntas são utilizadas apenas para ilustrar a complexidade da interação entre cadeias do ERC20.

Atualmente, muitas soluções de dimensionamento usam soluções de lista de permissões + inventário manual para evitar vários problemas complexos e situações de limite.

A Arbitrum usa o sistema Gateway para resolver a maioria dos pontos problemáticos da interação entre cadeias ERC20, com os seguintes recursos:

• Os componentes do gateway aparecem em pares em L1 e L2. O Gateway Router é responsável por manter mapeamentos de endereços entre o Token L1<->Token L2, bem como entre alguns tokens <-> alguns gateways.
• Os gateways podem ser divididos em gateways StandardERC20, gateways personalizados genéricos, gateways personalizados, etc., para resolver diferentes tipos e problemas funcionais de ponte ERC20.

Vamos tomar a interação entre cadeias WETH relativamente simples como um exemplo para ilustrar a necessidade de um gateway personalizado.

WETH é um equivalente ERC20 de ETH. Como o éter é a moeda principal, muitas funções complexas em dApps não são possíveis, por isso é necessário um equivalente ERC20. Transfira alguns ETH para o contrato WETH, eles serão bloqueados no contrato e a mesma quantidade de WETH será gerada.

Da mesma forma, também é possível queimar WETH e tirar ETH. **Obviamente, a quantidade de WETH em circulação e a quantidade de ETH Lock-up Position será sempre de 1:1. **

Se agora cruzarmos a interação WETH diretamente em L2, encontraremos alguns problemas estranhos:

• Não é possível desembrulhar WETH em ETH em L2 porque não há posição de bloqueio correspondente a ETH em L2.
• A função Wrap pode ser usada, mas esses WETH recém-gerados não podem ser descapsulados como ETH em L1 se cruzarem de volta para L1, porque os contratos WETH em L1 e L2 não são “simétricos”.

Obviamente, isso viola os princípios de design do WETH. **Então, quando WETH é interação de cadeia cruzada, seja um depósito ou um levantamento, ele precisa ser desembrulhado em ETH primeiro, e depois cruzado para o lado oposto e, em seguida, envolvido em WETH. É aqui que entra o WETH Gateway.

Outros Tokens com lógica mais complexa fazem o mesmo, exigindo gateways mais complexos e bem projetados para funcionar corretamente em um ambiente de interação entre cadeias. O gateway personalizado da Arbitrum herda a lógica de interação entre cadeias de gateways comuns e permite que os desenvolvedores personalizem o comportamento de interação entre cadeias relacionado à lógica de token, que pode atender à maioria das necessidades.

Caixa de entrada atrasada

A contrapartida para o SequencerInbox é a Caixa de Entrada Atrasada (Caixa de Entrada Atrasada). Como a caixa rápida é dedicada a receber o lote de transações L2 publicado pelo sequenciador, todas as transações que não foram pré-processadas pelo sequenciador na rede L2 não devem aparecer no contrato de caixa rápida.

**A primeira função da caixa lenta é lidar com o comportamento de carregamento de L1 para L2. **O utilizador faz um depósito através da Slow Box, e o sequenciador ouve-o e depois reflete-o em L2, e finalmente o registo de depósito será incluído na sequência de transações L2 pelo sequenciador e enviado para a Caixa de Entrada do Sequencer.

Neste exemplo, não é apropriado que o usuário envie a transação de depósito diretamente para a Caixa de Entrada do Sequencer, porque a transação enviada para a Caixa de Entrada do Sequencer interferirá na ordem normal da transação da Camada 2 e, em seguida, afetará o trabalho do sequenciador.

A segunda função da caixa lenta é resistir à censura. **As transações enviadas diretamente pelos usuários para o contrato Slowbox serão coletadas pelo sequenciador dentro de 10 minutos. Mas se o sequenciador ignorar maliciosamente o seu pedido, a slowbox também tem uma função de inclusão forçada:

Se a transação for enviada para a Caixa de Entrada Atrasada, após 24 horas, a transação na Caixa Lenta não foi incluída na sequência de transações pelo sequenciador, O usuário pode acionar manualmente a função de inclusão de força na Camada 1, e as solicitações de transação ignoradas pelo sequenciador são agrupadas à força na Caixa de Entrada do Sequenciador Fastbox, e então elas serão monitoradas por todos os nós do Arbitrum One e serão incluídas à força na sequência de transações da Camada 2.

Como mencionamos anteriormente, os dados no fastbox são a entidade de dados históricos de L2. Portanto, no caso de censura maliciosa, ** pode finalmente incluir instruções de transação no livro-razão L2 através da caixa lenta, que cobre cenários como retiradas forçadas para escapar da Camada 2. **

Pode-se ver a partir disso que, para qualquer direção e nível de transações, o sequenciador não será capaz de revisá-lo permanentemente no final.

Várias funções principais do Slowbox Inbox:

• depositETH(), a função mais simples para depositar ETH.
• createRetryableTicket(), que pode ser usado para depositar ETH e ERC20, bem como mensagens. Em comparação com depositETH(), tem maior flexibilidade, como a capacidade de especificar o endereço de recebimento de L2 após o depósito.
• forceInclusion(), que é a função de agregação forçada, pode ser chamada por qualquer pessoa. Esta função verifica se uma transação submetida ao contrato Slowbox não foi processada após 24 horas. Se as condições forem cumpridas, a mensagem será agregada à força.

No entanto, deve-se notar que a função de inclusão de força está realmente localizada no contrato Slowbox, apenas para facilitar a compreensão, vamos colocá-la aqui no Slowbox e explicá-la em conjunto.

Caixa de saída

A caixa de saída está relacionada apenas com levantamentos, o que pode ser entendido como um sistema de registo e gestão do comportamento de levantamento:**

• Sabemos que as retiradas da ponte oficial do Arbitrum precisam esperar o final do período de desafio de cerca de 7 dias antes que a retirada possa ser implementada após o Rollup Block ser finalizado. No final do período de desafio, o usuário envia a Prova Merkle correspondente ao contrato de Caixa de Saída na Camada 1, que se comunica com outros contratos funcionais (como desbloquear ativos bloqueados em outros contratos) e, finalmente, conclui a retirada.
• O contrato OutBox registará quais as mensagens de interação entre cadeias L2 a L1 que foram processadas para evitar que alguém submeta repetidamente pedidos de levantamento executados. Ele usa mapeamento(uint256 => bytes32) spen público para registrar o índice gasto da solicitação de retirada e a correspondência entre as informações, se mapeamento[spentIndex] != bytes32(0), o pedido já foi retirado. O princípio é semelhante ao contador de transações nonce que impede ataques de replay.

Abaixo, tomaremos o ETH como exemplo para explicar completamente o processo de depósito e retirada. A diferença entre ERC20 e ERC20 é que ele apenas passa pelo Gateway, então não vou repeti-lo.

Depósito ETH

1. O usuário chama a função depositETH() do Slowbox.

2. A função continuará a chamar bridge.enqueueDelayedMessage(), gravar a mensagem no contrato de ponte e enviar ETH para o contrato de ponte. **Todos os fundos de depósito ETH são mantidos no contrato de transição, que é equivalente a um endereço de depósito. **

3. O sequenciador ouve a mensagem de depósito na caixa lenta e reflete a operação de depósito na base de dados L2, para que os utilizadores possam ver os ativos que depositaram na rede L2.

4. O sequenciador incluirá o registo de depósito no lote e enviá-lo-á para o contrato Express em L1.

Levantamentos de ETH

1. O usuário chama a função withdrawEth() do contrato ArbSys em L2 para gravar a quantidade correspondente de ETH em L2.

2. O sequenciador envia o pedido de levantamento para a Quickbox.

**3.O Nó Validador cria um novo Bloco de Rollup com base na sequência de transações na Fastbox, que conterá as transações de retirada acima. **

4. Após o Rollup Block ter passado o período de desafio e ser confirmado, o usuário pode chamar a função Outbox.ute Transaction() em L1 para provar que os parâmetros são dados pelo contrato ArbSys acima mencionado.

5. Após o contrato de caixa de saída confirmar que está correto, a quantidade correspondente de ETH na ponte desbloqueada é enviada para o usuário.

Pagamentos rápidos

Retiradas usando a ponte oficial do Optimistic Rollup resultarão em um período de espera para o período de desafio. Podemos contornar esse problema com pontes privadas de interação entre cadeias de terceiros:

• Troca de bloqueio atômico. Este método só permite que as duas partes troquem ativos dentro de suas respetivas cadeias, e é atômico, desde que uma das partes forneça uma pré-imagem, ambas as partes definitivamente obterão os ativos que merecem. Mas o problema é que a liquidez é relativamente escassa e é necessário encontrar contrapartes peer-to-peer.
• Testemunhe a ponte de interação entre cadeias. **O tipo geral de ponte de interação entre cadeias é uma ponte testemunha. Os utilizadores submetem os seus próprios pedidos de levantamento ao operador da ponte ou pool de liquidez de terceiros. Depois que a testemunha descobre que a interação entre cadeias foi submetida ao contrato de caixa rápida L1, ele pode transferir dinheiro diretamente para o usuário do lado L1. Essa abordagem usa essencialmente outro sistema de consenso para monitorar a Camada 2 e operar com base nos dados comprometidos com a Camada 1. **O problema é que o fator de segurança neste modo não é tão alto quanto a ponte oficial do Rollup. **

Pagamentos forçados

force Inclusion() é usado para combater a censura do sequenciador e pode ser usado para qualquer transação local L2, L1-to-L2 e L2-to-L1. A censura maliciosa do sequenciador afetou seriamente a experiência de negociação e, na maioria dos casos, optaremos por retirar e deixar L2, então o seguinte é um exemplo de retirada forçada para introduzir o uso de forceInclusion.

Lembre-se de que, na etapa de retirada de ETH, apenas as etapas 1 e 2 envolvem a revisão do sequenciador, portanto, apenas essas duas etapas precisam ser alteradas:

• Chame inbox.sendL2Message() no contrato slowbox em L1, e o parâmetro de entrada é o parâmetro que precisa ser inserido ao chamar withdrawEth() em L2. A mensagem é compartilhada com o contrato de ponte na L1.
• Depois de esperar pelo período de espera de agregação forçada de 24 horas, chame a força Inclusion() na caixa rápida para forçar a coleta, e o contrato de caixa rápida verificará se há uma mensagem correspondente na ponte.

O usuário final pode retirar na caixa de saída, e o resto das etapas são as mesmas que os saques normais.

Além disso, os tutoriais de arbitrum também têm tutoriais detalhados sobre como usar o Arb SDK para orientar os usuários sobre como usar forceInclusion() para conduzir transações locais L2 e transações L2 para L1.