O ex-embaixador técnico da Arbitrum explica a estrutura dos componentes da Arbitrum (Parte 2)

Como a Arbitrum lida com mensagens entre cadeias e transações resistentes à censura? Qual é o seu modelo de ponte de cadeia cruzada?

Escrito por: Luo Benben, ex-embaixador técnico da Arbitrum e contribuidor geek web3

No artigo anterior* “Ex-embaixador técnico do Arbitrum interpreta a estrutura dos componentes do Arbitrum (Parte 1)”**, introduzimos o sequenciador, validador, contrato da caixa de entrada do sequenciador, bloco de rollup e prova de fraude não interativa nos componentes principais do Arbitrum No artigo de hoje, focaremos nos componentes relacionados a mensagens entre cadeias e entradas de transações resistentes à censura entre os componentes principais do Arbitrum. *

No artigo anterior, mencionamos que o contrato Sequencer Inbox recebe especificamente o pacote de dados de transação Batch publicado pelo sequenciador na Camada1. Ao mesmo tempo, ressaltamos que Caixa de entrada do sequenciador também é chamada de caixa rápida, em oposição a caixa lenta Caixa de entrada atrasada (conhecida como Caixa de entrada). Abaixo, forneceremos uma explicação detalhada dos componentes relacionados às mensagens entre cadeias, como a Caixa de entrada atrasada.

Princípios de cadeia cruzada e ponte

As transações entre cadeias podem ser divididas em L1 a L2 (recarga) e L2 a L1 (saque). Observe que a recarga e a retirada mencionadas aqui não estão necessariamente relacionadas a ativos de cadeia cruzada, mas podem ser mensagens que não incluem ativos diretamente. Portanto, essas duas palavras representam apenas duas direções de comportamentos relacionados entre cadeias.

Em comparação com as transações L2 puras, as transações entre cadeias trocam informações em dois sistemas diferentes, L1 e L2, portanto o processo é mais complicado.

Além disso, o que normalmente chamamos de comportamento de cadeia cruzada é cadeia cruzada em duas redes não relacionadas usando uma ponte de cadeia cruzada de modo testemunha. A segurança dessa cadeia cruzada depende da ponte de cadeia cruzada. Operadores, roubo de cadeia cruzada. pontes em cadeia baseadas no modelo testemunha ocorreram com frequência na história.

O comportamento cross-chain entre Rollup e a rede principal ETH é essencialmente diferente do cross-chain mencionado acima, porque o estado da Camada2 é determinado pelos dados registrados na Camada1,** contanto que você esteja usando o Rollup oficial. a ponte de cadeia cruzada é absolutamente segura em sua estrutura operacional. **

Isso também destaca a essência do Rollup. Do ponto de vista do usuário, ele só parece uma cadeia independente, mas na verdade a chamada “**Layer2” é apenas uma janela de exibição rápida aberta pelo Rollup para os usuários. Seu tipo de cadeia real A estrutura ainda está gravado na Camada1. **Portanto, podemos pensar em L2 como meia cadeia, ou “uma cadeia criada na Camada1”.

Tickets repetíveisRetentáveis

Deve-se notar que as cadeias cruzadas são assíncronas e não atômicas.É impossível saber o resultado após a confirmação de uma transação como em uma cadeia, nem pode garantir que algo acontecerá do outro lado em um determinado momento. . Portanto, a cadeia cruzada pode falhar devido a alguns problemas leves, mas desde que os meios corretos sejam usados, como Tíquete Repetido, problemas difíceis, como congestionamentos de fundos, não ocorrerão.

Tíquetes retentáveis são as ferramentas básicas usadas ao depositar através da ponte oficial do Arbitrum. Serão usados depósitos ETH e ERC20. Seu ciclo de vida é dividido em três etapas:

**1. Envie o ticket em L1. **Use o método createRetryableTicket() no contrato Delayed Inbox para criar um ticket de recarga e enviá-lo.

**2. Resgate automático em L2. **Na maioria dos casos, o classificador pode ajudar automaticamente os usuários a pagar as contas sem operações manuais subsequentes.

**3. Resgate manual em L2. **Em alguns casos extremos, como um aumento repentino nos preços do gás no L2 e gás pré-pago insuficiente no bilhete, o pagamento automático não pode ser feito. Neste momento, é necessária a operação manual pelo usuário.

Observe que se o resgate automático falhar, a nota precisará ser resgatada manualmente dentro de 7 dias; caso contrário, a nota será excluída (os fundos serão perdidos permanentemente) ou uma taxa precisará ser paga para salvar a nota e renovar o aluguel.

Além disso, embora o processo de retirada da ponte oficial da Arbitrum tenha certa semelhança simétrica com o comportamento de recarga, não existe o conceito de Retryables, por um lado, pode ser entendido a partir do próprio protocolo Rollup, e por outro lado, podemos entendê-lo a partir de algumas diferenças:

• **Não há resgate automático durante o processo de saque, **porque o EVM não possui cronômetro ou automação, e o resgate automático pode ser feito em L2, que é implementado com o auxílio do sequenciador, portanto os usuários em L1 devem manualmente interagir com o contrato Outbox para reivindicar recursos de recuperação.
• **Não há problema de vencimento do ticket ao sacar dinheiro. **Enquanto o período do desafio tiver passado, você poderá recebê-lo a qualquer momento.

Gateway de cadeia cruzada de ativos ERC-20

Os ativos ERC-20 de cadeia cruzada são complexos. Podemos pensar em diversas questões:

• Um token implantado em L1, como implantá-lo em L2?
• O contrato L2 correspondente precisa ser implantado manualmente com antecedência ou o sistema pode implantar automaticamente contratos de ativos para tokens que passaram, mas ainda não implantaram um contrato? *Para ativos ERC-20 em L1, qual é o endereço do contrato correspondente em L2? Deveria ser consistente com L1?
• Como fazer cross-chain de tokens emitidos nativamente de L2 para L1?
• Como os tokens com funções especiais, como tokens de rebase com quantidades ajustáveis e tokens com juros de crescimento automático, podem ser interligados?

Não vamos responder a todas essas perguntas porque elas são complexas demais para serem reveladas. Essas perguntas são usadas apenas para ilustrar a complexidade da cadeia cruzada do ERC20.

Atualmente, muitas soluções de expansão usam soluções de lista branca + lista manual para evitar vários problemas complexos e condições de limite.

**Arbitrum usa o sistema Gateway para resolver a maioria dos pontos problemáticos da cadeia cruzada do ERC20. **Ele possui os seguintes recursos:

*Os componentes do gateway aparecem em pares em L1 e L2.

• **Gateway Router é responsável por manter o mapeamento de endereços entre Token L1<->Token L2, ** e o mapeamento entre algum token<->algum gateway.
• O gateway em si pode ser dividido em gateway StandardERC20, gateway genérico personalizado, gateway personalizado, etc. para resolver diferentes tipos e funções de problemas de ponte ERC20.

Vamos pegar o cross-chain WETH relativamente simples como exemplo para ilustrar a necessidade de customizar o gateway.

WETH é um equivalente ERC20 de ETH. Como moeda principal, o Ether não pode implementar funções complexas em muitos dApps, portanto, é necessário um equivalente ERC20. Transfira alguns ETH para o contrato WETH, eles ficarão bloqueados no contrato e será gerada a mesma quantidade de WETH.

Da mesma forma, o WETH também pode ser destruído e o ETH retirado. Obviamente, o número de WETH em circulação e de ETH bloqueado é sempre 1:1. **

Se agora cruzarmos WETH diretamente com L2, encontraremos alguns problemas estranhos:

• É impossível desembrulhar WETH em ETH em L2 porque não há ETH correspondente para bloqueio em L2.
• A função Wrap pode ser usada, mas se esses WETH recém-gerados forem cruzados de volta para L1, eles não poderão ser desencapsulados em ETH em L1 porque os contratos WETH em L1 e L2 não são “simétricos”**.

Obviamente isto viola os princípios de design do WETH. **Então, quando WETH é cross-chain, seja recarregando ou retirando, ele precisa primeiro ser desembrulhado em ETH, depois cruzado para o outro lado e depois embrulhado em WETH. **Esta é a função do WETH Gateway.

O mesmo vale para outros tokens com lógica mais complexa, que requerem um Gateway mais complexo e cuidadosamente projetado para funcionar corretamente em um ambiente cross-chain. O Gateway personalizado da Arbitrum herda a lógica de comunicação entre cadeias do Gateway comum e permite que os desenvolvedores personalizem o comportamento entre cadeias relacionado à lógica do token, que pode atender à maioria das necessidades.

Caixa de entrada atrasada

Correspondendo à caixa rápida, também conhecida como SequencerInbox, está a caixa lenta Inbox (nome completo Delayed Inbox)**. Por que deveria haver uma distinção entre velocidade e lentidão? Como a fast box é dedicada a receber o lote de transações L2 emitido pelo sequenciador, todas as transações que não foram pré-processadas pelo sequenciador na rede L2 não devem aparecer no contrato da fast box.

**A primeira função da caixa lenta é lidar com o comportamento de recarga de L1 a L2. **O usuário recarrega através da caixa lenta, e o sequenciador monitora e depois reflete no L2.Finalmente, o registro de recarga será incluído na sequência de transação L2 pelo sequenciador e enviado para a caixa de entrada do sequenciador do contrato da caixa rápida.

Neste exemplo, não é apropriado que os usuários enviem transações de recarga diretamente para a caixa expressa, porque as transações enviadas para a caixa expressa Sequencer Inbox interferirão na classificação normal de transações da Camada 2 e afetarão o trabalho do sequenciador.

A segunda função da slow box é resistir à censura. Os usuários enviam transações diretamente para o contrato de caixa lenta, e o classificador geralmente as agrega na caixa rápida em 10 minutos. Mas se o classificador ignorar maliciosamente sua solicitação, a caixa lenta também terá uma função de forçar inclusão:

Se uma transação for enviada para a Caixa de Entrada Atrasada, e após 24 horas, a transação na caixa lenta não tiver sido incluída na sequência de transações pelo sequenciador, ** o usuário pode acionar manualmente a função de inclusão forçada na Camada1, ** para ignore-o pelo sequenciador As solicitações de transação são coletadas à força na caixa de entrada do sequenciador e serão monitoradas por todos os nós do Arbitrum One e serão incluídas à força na sequência de transação da camada 2. **

Como acabamos de mencionar, os dados na caixa rápida são a entidade de dados históricos de L2. Portanto, no caso de censura maliciosa, as instruções de transação podem ser finalmente incluídas no razão L2 através da caixa lenta, que cobre cenários como retiradas forçadas e fuga da Camada 2. **

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

Várias funções principais da caixa de entrada lenta:

• depositETH(), a função mais simples para depositar ETH.
• createRetryableTicket(), que pode ser usado para ETH, ERC20 e recarga de mensagens. Comparado com depositETH(), tem maior flexibilidade, por exemplo, você pode especificar o endereço de pagamento L2 após o depósito, etc.
• forceInclusion(), que é a função de coleta forçada, pode ser chamada por qualquer pessoa. Esta função verificará se uma transação submetida ao contrato slow box não foi processada após 24 horas. Se as condições forem atendidas, as mensagens serão coletadas à força.

No entanto, deve-se notar que a função de inclusão de força está na verdade localizada no contrato de caixa rápida, apenas para facilitar o entendimento, iremos explicá-la juntos na caixa lenta.

Caixa de saída Caixa de saída

O Outbox está relacionado apenas a saques e pode ser entendido como um sistema de registro e gerenciamento de saques:

• Sabemos que as retiradas da ponte oficial do Arbitrum precisam esperar cerca de 7 dias para que o final do período de desafio e o Rollup Block sejam finalizados antes que a retirada possa ser implementada. Após o término do período de desafio, o usuário envia a Prova Merkle correspondente ao contrato Outbox na Camada1, que então se comunica com contratos para outras funções (como desbloquear ativos bloqueados em outros contratos) e, finalmente, conclui a retirada.
• O contrato OutBox registrará quais mensagens cross-chain de L2 a L1 foram processadas para evitar que alguém envie repetidamente solicitações de retirada executadas. isso passa
• mapeamento(uint256 => bytes32) gasto público, registra a correspondência entre o índice de gasto da solicitação de saque e a informação, se for mapeamento [spentIndex] != bytes32(0) então a solicitação foi retirada. O princípio é semelhante ao contador de transações Nonce para evitar ataques de repetição.

A seguir tomaremos o ETH como exemplo para explicar completamente o processo de depósito e retirada. A única diferença entre o ERC20 e o Gateway é que ele não será descrito em detalhes.

Depósito ETH

1. O usuário chama a função depositETH() da caixa lenta.

2. Esta 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 recarga de ETH são mantidos no contrato ponte, que equivale a um endereço de recarga. **

3. O sequenciador monitora as mensagens de recarga na caixa lenta e reflete a operação de recarga no banco de dados L2. Os usuários podem ver os ativos que recarregaram na rede L2.

4. O sequenciador inclui o registro de recarga no lote de transações e o envia ao contrato fast box em L1.

Retirada de ETH

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

2. O sequenciador envia a solicitação de saque para a caixa expressa.

3 **O nó validador cria um novo Bloco Rollup com base na sequência de transação na caixa rápida, que conterá a transação de retirada acima. **

4. Após o Rollup Block passar pelo 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 fornecidos pelo contrato ArbSys mencionado acima.

5. Depois que o contrato Outbox for confirmado como correto, a quantidade correspondente de ETH na ponte desbloqueada será enviada ao usuário.

Retirada rápida

**Se você usar a ponte oficial do Optimistic Rollup para sacar dinheiro, haverá um problema de espera pelo período de desafio. Podemos usar uma ponte cross-chain privada de terceiros para contornar esse problema: **

• Troca de bloqueio atômico. Este método apenas troca ativos entre as duas partes dentro de suas respectivas cadeias e é atômico. Desde que uma das partes forneça a pré-imagem, ambas as partes obterão definitivamente os ativos que merecem. Mas o problema é que a liquidez é relativamente escassa e é necessário encontrar contrapartes ponto a ponto.
• **Ponte de cadeia cruzada testemunha. **Tipos gerais de pontes de cadeia cruzada são pontes testemunhas. Os usuários enviam suas próprias solicitações de saque e os pontos de destino dos saques ao operador da ponte de terceiros ou do pool de liquidez. Depois que a testemunha descobrir que a transação entre cadeias foi submetida ao contrato de caixa rápida de L1, ela poderá transferir dinheiro diretamente para o usuário do lado L1. Esta abordagem utiliza essencialmente outro sistema de consenso para monitorar a Camada 2 e operar com base nos dados submetidos à Camada 1. **O problema é que o fator de segurança neste modo não é tão alto quanto o da ponte Rollup oficial. **

Retirada forçada

force Inclusão() A função de inclusão forçada é usada para resistir à revisão do sequenciador.Qualquer transação local L2, transação L1 para L2 e transação L2 para L1 pode ser implementada usando esta função. A revisão maliciosa do sequenciador afeta seriamente a experiência da transação. Na maioria dos casos, optaremos por retirar dinheiro e sair de L2. Portanto, o seguinte usa a retirada forçada como exemplo para introduzir o uso de forceInclusão.

**Lembre-se que nas etapas de retirada de ETH, apenas as etapas 1 e 2 envolvem revisão do sequenciador, portanto apenas estas duas etapas precisam ser alteradas: **

• Chame inbox.sendL2Message() no contrato slow box em L1. Os parâmetros de entrada são os parâmetros que precisam ser inseridos ao chamar retireEth() em L2. Esta mensagem será compartilhada com o contrato ponte em L1.
• Após aguardar o período de espera de inclusão forçada de 24 horas, chame force Inclusão() na caixa rápida para realizar a inclusão forçada. O contrato da caixa rápida verificará se há uma mensagem correspondente na ponte.

Os usuários finais podem sacar dinheiro na Caixa de saída e as etapas restantes são iguais às retiradas normais.

Além disso, arbitrum-tutorials também possui tutoriais detalhados sobre como usar o Arb SDK para orientar os usuários sobre como realizar transações locais L2 e transações L2 para L1 por meio de forceInclusion().