Texto principal: Em artigos anteriores, mencionamos que o contrato Sequencer Inbox foi projetado especificamente para receber lotes de dados de transações publicados pelo sequenciador na Camada 1. Ao mesmo tempo, destacamos que a Caixa de entrada do sequenciador também é chamada de "caixa rápida", sendo que a contrapartida é a Caixa de entrada atrasada (chamada de Caixa de entrada). Em seguida, forneceremos uma explicação detalhada dos componentes relacionados à transmissão de mensagens entre cadeias, como o Delayed Inbox.

O princípio da cadeia cruzada e da ponte

As transações entre cadeias podem ser divididas em L1 para L2 (depósito) e L2 para L1 (saque). Observe que o depósito e a retirada mencionados aqui não estão necessariamente relacionados 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 à cadeia cruzada.

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

Além disso, o que normalmente chamamos de comportamento de cadeia cruzada é a cadeia cruzada em duas redes não relacionadas usando uma ponte de cadeia cruzada no modo testemunha. A segurança dessa cadeia cruzada depende da ponte de cadeia cruzada. Historicamente, as pontes entre cadeias baseadas em um modo de testemunha têm sofrido incidentes de roubo com frequência.

Em contrapartida, o comportamento entre cadeias entre o Rollup e a rede principal da Ethereum é fundamentalmente diferente das operações entre cadeias mencionadas anteriormente. Isso ocorre porque o estado da Camada 2 é determinado pelos dados registrados na Camada 1. Desde que o senhor use a ponte oficial de cadeia cruzada do Rollup, sua estrutura operacional é absolutamente segura.

Isso também destaca a essência do Rollup, que, da perspectiva do usuário, aparece como uma cadeia independente. No entanto, na realidade, a chamada "Camada 2" é apenas uma janela de exibição rápida aberta pelo Rollup para os usuários, e sua verdadeira estrutura em cadeia ainda está registrada na Camada 1. Portanto, podemos considerar a L2 como metade de uma cadeia, ou como uma "cadeia criada na Camada 1".

Retryables

É importante observar que as operações entre cadeias são assíncronas e não atômicas. Diferentemente do que ocorre em uma única cadeia, em que o resultado de uma transação é conhecido após sua confirmação, as transações entre cadeias não podem garantir que determinados eventos ocorrerão no outro lado em um momento específico. Portanto, as transações entre cadeias podem falhar devido a problemas de soft, mas com os métodos corretos, como os Retryable Tickets, não haverá problemas como o bloqueio de fundos.

Os tickets recuperáveis são ferramentas básicas usadas ao depositar fundos por meio da ponte oficial da Arbitrum para tokens ETH e ERC20. Seu ciclo de vida consiste em três etapas:

1. Envio do tíquete em L1: Crie um tíquete de depósito usando o método createRetryableTicket() no contrato Delayed Inbox e envie-o.

2. Resgate automático no L2: Na maioria dos casos, o sequenciador pode resgatar automaticamente o tíquete para o usuário sem intervenção manual adicional.

3. Resgate manual em L2: Em certos casos extremos, como um aumento repentino nos preços do gás no L2, em que o gás pré-pago no bilhete é insuficiente, o resgate automático pode falhar. Nesses casos, é necessária a intervenção manual do usuário. Observe que, se o resgate automático falhar, o tíquete deverá ser resgatado manualmente em até 7 dias; caso contrário, o tíquete poderá ser excluído (resultando em perda permanente de fundos) ou exigir o pagamento de uma taxa para renovar seu aluguel.

Além disso, no processo de saque da ponte oficial do Arbitrum, embora haja alguma semelhança simétrica com o comportamento do depósito em termos de processo, não há o conceito de Retryables. Isso pode ser entendido tanto da perspectiva do próprio protocolo Rollup quanto examinando algumas diferenças:

• Não há resgate automático durante a retirada porque o EVM não tem temporizadores ou automação. Embora o resgate automático possa ser implementado em L2 com a ajuda do sequenciador, os usuários em L1 precisam interagir manualmente com o contrato Outbox para reivindicar seus ativos.

• Também não há problema de expiração do tíquete durante a retirada; desde que o período de desafio tenha passado, os ativos podem ser resgatados a qualquer momento.

Gateway de cadeia cruzada de ativos ERC-20

As transações entre cadeias envolvendo ativos ERC-20 são complexas. Podemos considerar várias questões:

• Como um token é implantado no L2 se ele foi implantado no L1?
• Seu contrato correspondente na L2 deve ser implantado manualmente com antecedência ou o sistema pode implantar automaticamente contratos de ativos para tokens que foram transferidos, mas ainda não implantados?
• Qual é o endereço de contrato de um ativo ERC-20 em L2 correspondente ao seu endereço em L1? Ele deve corresponder ao endereço em L1?
• Como os tokens emitidos nativamente no L2 são transferidos para o L1?
• Como os tokens com funcionalidades especiais, como os tokens de Rebase de suprimento ajustável ou os tokens de auto-staking, fazem o cross-chain?

Não pretendemos responder a todas essas perguntas, pois elas são muito complexas para serem abordadas de forma abrangente. Essas perguntas servem apenas para ilustrar a complexidade das transações entre cadeias do ERC-20.

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

A Arbitrum emprega um sistema de gateway para resolver a maioria dos pontos problemáticos das transações entre cadeias ERC20, apresentando as seguintes características:

• Os componentes do Gateway aparecem em pares em L1 e L2.
• O Gateway Router é responsável por manter os mapeamentos de endereço entre o Token L1 <-> Token L2 e algum token <-> algum gateway.
• O próprio gateway pode ser dividido em vários tipos, como gateway ERC20 padrão, gateway personalizado genérico, gateway personalizado, etc., para resolver problemas de ponte para diferentes tipos e funcionalidades de tokens ERC20.

Para ilustrar a necessidade de gateways personalizados, vamos considerar um exemplo relativamente simples de transferência WETH entre cadeias.

O WETH é um equivalente ERC20 do ETH. Como o Ether serve como moeda principal, é impossível obter diretamente muitas funcionalidades complexas nos dApps. Por isso, é necessário um equivalente ERC20 como o WETH. Ao depositar um pouco de ETH no contrato WETH, eles são bloqueados dentro do contrato, gerando uma quantidade equivalente de WETH.

Da mesma forma, o WETH pode ser queimado para retirar ETH. Claramente, a quantidade circulante de WETH e a quantidade bloqueada de ETH sempre manterão uma proporção de 1:1.

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

• É impossível desdobrar o WETH em ETH no L2 porque não há ETH correspondente para bloqueio no 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 desdobrados em ETH em L1 porque os contratos WETH em L1 e L2 não são "simétricos" 。

Claramente, isso viola os princípios de design do WETH. Portanto, ao cruzar a cadeia cruzada de WETH, seja depositando ou retirando, é necessário desembrulhar primeiro em ETH, depois cruzar e desembrulhar novamente em WETH. É nesse ponto que o WETH Gateway entra em ação.

Da mesma forma, para outros tokens com lógicas mais complexas, eles exigem Gateways mais sofisticados e cuidadosamente projetados para funcionar adequadamente em um ambiente entre cadeias. O gateway personalizado da Arbitrum herda a lógica de comunicação entre cadeias de um gateway padrão e permite que os desenvolvedores personalizem os comportamentos entre cadeias relacionados às lógicas de token, satisfazendo a maioria dos requisitos.

Caixa de entrada atrasada

A contraparte da SequencerInbox, também conhecida como caixa rápida, é a Inbox (oficialmente chamada de Delayed Inbox). Por que ele faz distinção entre caixas rápidas e atrasadas? Como o fast box foi projetado especificamente para receber lotes de transações L2 publicadas pelo sequenciador, todas as transações não pré-processadas pelo sequenciador na rede L2 não devem aparecer no contrato do fast box.

A primeira função da caixa lenta é lidar com o comportamento de depósito de L1 para L2. Os usuários iniciam depósitos por meio da caixa lenta, que o sequenciador reflete em L2. Eventualmente, esse registro de depósito será incluído na sequência de transações L2 pelo sequenciador e enviado ao contrato de caixa rápido, o SequencerInbox.

Nesse cenário, não é adequado que os usuários enviem diretamente transações de depósito para a caixa rápida porque as transações enviadas para a SequencerInbox interfeririam no sequenciamento normal de transações da Camada 2, afetando, assim, a operação do sequenciador.

A segunda função da caixa atrasada é a resistência à censura. As transações enviadas diretamente ao contrato de caixa atrasado são normalmente agregadas ao caixa rápido em 10 minutos pelo sequenciador. No entanto, se o sequenciador ignorar maliciosamente sua solicitação, a caixa de atraso tem um recurso de inclusão forçada:

Se uma transação for enviada para a Delayed Inbox e permanecer não agregada à sequência de transações pelo sequenciador após 24 horas, os usuários poderão acionar manualmente a função de inclusão forçada na Camada 1. Essa ação força as solicitações de transação ignoradas pelo sequenciador a serem agregadas na caixa rápida, a SequencerInbox, e, posteriormente, a serem detectadas por todos os nós do Arbitrum One, sendo assim incluídas à força na sequência de transações da Camada 2.

Como mencionamos anteriormente, os dados na caixa rápida representam a entidade de dados históricos de L2. Portanto, em casos de censura maliciosa, as transações podem ser incluídas no ledger L2 usando a caixa atrasada, abrangendo cenários como retiradas forçadas da Camada 2.

A partir disso, pode-se ver que o sequenciador não pode censurar permanentemente as transações em nenhuma direção ou camada.

Várias funções principais da caixa lenta Inbox são as seguintes:

• depositETH(): Essa função é o método mais simples para depositar ETH.
• createRetryableTicket(): Essa função pode ser usada para depositar ETH, tokens ERC20 e mensagens. Comparado ao depositETH(), ele oferece maior flexibilidade, como a especificação do endereço de recebimento em L2 após o depósito.
• forceInclusion(): Também conhecida como função de inclusão forçada, que pode ser chamada por qualquer pessoa. Essa função verifica se uma transação enviada ao contrato de caixa lento não foi processada após 24 horas. Se a condição for atendida, a função agrega forçosamente a mensagem.

No entanto, é importante observar que a função forceInclusion() reside, na verdade, no contrato da caixa rápida. Para maior clareza, discutimos isso aqui juntamente com as funções da caixa lenta.

Caixa de saída

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

• Sabemos que os saques na ponte oficial do Arbitrum precisam esperar cerca de 7 dias para que o período de desafio termine, e o saque só pode ser implementado após a finalização do bloco de rollup. Após o término do período de desafio, o usuário envia a Prova de Merkle correspondente para o contrato Outbox na Camada 1, que então se comunica com contratos para outras funções (como desbloqueio de ativos bloqueados em outros contratos) e, finalmente, conclui a retirada.
• O contrato OutBox registra quais mensagens de cadeia cruzada L2 para L1 foram processadas para evitar que alguém envie repetidamente solicitações de retirada executadas. Isso é feito por meio de um mapeamento chamado spent, que associa os índices spent das solicitações de retirada às informações correspondentes. Se mapping[spentIndex] != bytes32(0), isso indica que a solicitação já foi retirada. O princípio é semelhante ao de um nonce de contador de transações, usado para evitar ataques de repetição.

A seguir, explicaremos o processo de depósito e retirada usando a ETH como exemplo. O processo para tokens ERC20 é semelhante, com o acréscimo de um Gateway, mas não entraremos em detalhes sobre isso aqui.

Depósito de ETH

1. O usuário chama a função depositETH() da Delayed Inbox.
2. Em seguida, essa função chama bridge.enqueueDelayedMessage(), que registra a mensagem no contrato de ponte e envia o ETH para o contrato de ponte. Todos os fundos de ETH depositados são mantidos no contrato de ponte, atuando como um endereço de depósito.
3. O sequenciador monitora a mensagem de depósito na Delayed Inbox e reflete a operação de depósito no banco de dados L2. Os usuários podem ver seus ativos depositados na rede L2.
4. O sequenciador inclui o registro de depósito em um lote de transações e o envia para o contrato Fast Inbox em L1.

Retirada de ETH

1. O usuário chama a função withdrawEth() do contrato ArbSys no L2 e queima a quantidade correspondente de ETH no L2.

2. O sequenciador envia a solicitação de retirada para a caixa rápida.

3. O nó Validator cria um novo bloco de rollup com base na sequência de transações na caixa rápida, que conterá as transações de saque acima.

4. Depois que o bloco de rollup passar pelo período de desafio e for confirmado, o usuário poderá chamar a função Outbox.execute Transaction() no L1 para provar que os parâmetros são fornecidos pelo contrato da ArbSys mencionado acima.

5. Após a confirmação de que o contrato da Outbox está correto, a quantidade correspondente de ETH na ponte será desbloqueada e enviada ao usuário.

Retiradas rápidas

O uso da ponte oficial de rollup otimista envolve a espera por um período de desafio. Para contornar esse problema, podemos utilizar uma ponte privada de cadeia cruzada de terceiros:

• Troca atômica de permuta: Nessa abordagem, os ativos são trocados entre as partes dentro de suas respectivas cadeias, e é atômica, ou seja, se uma parte fornecer a pré-imagem, ambas as partes poderão obter os ativos correspondentes. No entanto, a liquidez é relativamente escassa, exigindo a busca de contrapartes entre pares.
• Ponte de cadeia cruzada baseada em testemunha: A maioria dos tipos de pontes de cadeia cruzada se enquadra nessa categoria. Os usuários enviam suas solicitações de saque, especificando o destino como o operador ou o pool de liquidez da ponte de terceiros. Quando a testemunha descobre que a transação entre cadeias foi enviada para o contrato Fast Inbox em L1, ela pode transferir fundos diretamente para o usuário em L1. Essencialmente, esse método usa outro sistema de consenso para monitorar a Camada 2 e realizar operações com base nos dados enviados à Camada 1. No entanto, o nível de segurança nesse modo é menor em comparação com a ponte oficial de rollup.

Forçar a retirada

A função forceInclusion() é usada para neutralizar a censura do sequenciador. Ele pode ser aplicado a quaisquer transações locais L2, transações L1 para L2 e transações L2 para L1. Como a censura maliciosa do sequenciador afeta significativamente a experiência da transação, muitas vezes optamos por nos retirar do L2. Abaixo está um exemplo de uso de forceInclusion() para retiradas forçadas:

No contexto das retiradas de ETH, somente as etapas 1 e 2 envolvem censura do sequenciador. Portanto, só precisamos modificar essas duas etapas:

• Chame inbox.sendL2Message() no contrato Delayed Inbox em L1, com os parâmetros necessários ao chamar withdrawEth() em L2. Essa mensagem é compartilhada com o contrato de ponte em L1.
• Depois de aguardar o período de espera de 24 horas para forçar a inclusão, chame forceInclusion() no contrato do Fast Inbox para forçar a inclusão. O contrato do Fast Inbox verificará se há uma mensagem correspondente na ponte.

Por fim, os usuários podem sacar do Outbox, e as etapas restantes são as mesmas de um processo normal de saque.

Além disso, há tutoriais detalhados no repositório arbitrum-tutorials que orientam os usuários sobre como realizar transações locais L2 e transações L2 para L1 usando forceInclusion() por meio do SDK do Arb.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [Geek Web3], Todos os direitos autorais pertencem ao autor original[Luo Benben, ex-embaixador técnico da Arbitrum, colaborador da Geek Web3]]. Se houver alguma objeção a essa reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.