Texto principal: Em artigos anteriores, mencionámos que o contrato Sequencer Inbox foi especificamente concebido para receber lotes de dados de transacções publicados pelo sequenciador no nível 1. Ao mesmo tempo, salientámos que a Caixa de entrada do sequenciador também é referida como a "caixa rápida", sendo a sua contrapartida a Caixa de entrada atrasada (referida como Inbox). Em seguida, apresentaremos uma explicação pormenorizada dos componentes relacionados com a transmissão de mensagens entre cadeias, como a caixa de entrada atrasada.

O princípio da cadeia cruzada e da ponte

As transacções entre cadeias podem ser divididas em L1 para L2 (depósito) e L2 para L1 (levantamento). Note que o depósito e a retirada aqui mencionados não estão necessariamente relacionados com activos de cadeia cruzada, mas podem ser mensagens que não incluem diretamente activos. Assim, estas duas palavras representam apenas duas direcções de comportamentos relacionados com a cadeia cruzada.

Em comparação com as transacções L2 puras, as transacções entre cadeias trocam informações em dois sistemas diferentes, L1 e L2, pelo 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 desta cadeia cruzada depende da ponte de cadeia cruzada. Historicamente, as pontes entre cadeias baseadas num modo de testemunho têm registado frequentemente incidentes de roubo.

Em contraste, o comportamento entre cadeias entre o Rollup e a rede principal Ethereum é fundamentalmente diferente das operações entre cadeias acima mencionadas. Isto deve-se ao facto de o estado da camada 2 ser determinado pelos dados registados na camada 1. Desde que utilize a ponte de cadeia cruzada oficial do Rollup, a sua estrutura operacional é absolutamente segura.

Isto também realça a essência do Rollup, que, na perspetiva do utilizador, aparece como uma cadeia independente. No entanto, na realidade, a chamada "Camada 2" é apenas uma janela de visualização rápida aberta pelo Rollup aos utilizadores, e a sua verdadeira estrutura em cadeia continua a ser registada na Camada 1. Assim, podemos considerar L2 como meia cadeia, ou como uma "cadeia criada na Camada 1".

Recuperáveis

É importante notar que as operações entre cadeias são assíncronas e não atómicas. Ao contrário do que acontece numa única cadeia, em que o resultado de uma transação é conhecido assim que é confirmado, as transacções entre cadeias não podem garantir que determinados eventos ocorrerão do outro lado num momento específico. Por conseguinte, as transacções entre cadeias podem falhar devido a problemas de software, mas com os métodos correctos, tais como os bilhetes que podem ser repetidos, não haverá problemas como os fundos ficarem presos.

Os bilhetes recuperáveis são ferramentas básicas usadas ao depositar fundos através da ponte oficial Arbitrum para os tokens ETH e ERC20. O seu ciclo de vida é composto por três etapas:

1. Submeter o bilhete em L1: Crie um bilhete de depósito utilizando o método createRetryableTicket() no contrato Delayed Inbox e submeta-o.

2. Resgate automático no L2: Na maioria dos casos, o sequenciador pode resgatar automaticamente o bilhete para o utilizador sem intervenção manual adicional.

3. Resgate manual em L2: Em certos casos extremos, como um aumento súbito do preço do gás no L2, em que o gás pré-pago no bilhete é insuficiente, o resgate automático pode falhar. Nestes casos, é necessária a intervenção manual do utilizador. Tenha em atenção que, se o resgate automático falhar, o bilhete deve ser resgatado manualmente no prazo de 7 dias; caso contrário, o bilhete pode ser eliminado (resultando na perda permanente de fundos) ou exigir o pagamento de uma taxa para renovar o seu aluguer.

Para além disso, no processo de levantamento da ponte oficial Arbitrum, embora exista alguma semelhança simétrica com o comportamento do depósito em termos de processo, não existe o conceito de Retryables. Isto pode ser entendido tanto da perspetiva do próprio protocolo Rollup como através da análise de algumas diferenças:

• Não há resgate automático durante o levantamento porque a EVM não dispõe de temporizadores nem de automatização. Enquanto o resgate automático pode ser implementado em L2 com a ajuda do sequenciador, os utilizadores em L1 precisam de interagir manualmente com o contrato Outbox para reclamar os seus activos.

• Também não existe a questão da expiração do bilhete durante a retirada; desde que o período de desafio tenha passado, os activos podem ser reclamados em qualquer altura.

Gateway de cadeia cruzada de activos ERC-20

As transacções entre cadeias que envolvem activos ERC-20 são complexas. Podemos considerar várias questões:

• Como é que um token é implantado em L2 se está implantado em L1?
• O seu contrato correspondente no L2 deve ser implantado manualmente com antecedência, ou o sistema pode implantar automaticamente contratos de activos para tokens que foram transferidos mas ainda não implantados?
• Qual é o endereço do contrato de um ativo ERC-20 em L2 correspondente ao seu endereço em L1? Deve corresponder ao endereço em L1?
• Como é que os tokens emitidos nativamente no L2 são transferidos para o L1?
• Como é que os tokens com funcionalidades especiais, tais como os tokens Rebase de fornecimento ajustável ou os tokens de auto-aposta, se cruzam na cadeia?

Não é nossa intenção responder a todas estas questões, uma vez que são demasiado complexas para serem abordadas de forma exaustiva. Estas perguntas destinam-se simplesmente a ilustrar a complexidade das transacções ERC-20 entre cadeias.

Atualmente, muitas soluções de escalonamento utilizam soluções de lista branca + lista manual para evitar vários problemas complexos e condições de fronteira.

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

• Os componentes da porta de entrada aparecem aos pares tanto em L1 como em L2.
• O Gateway Router é responsável por manter os mapeamentos de endereços entre o Token L1 <-> Token L2 e algum token <-> algum gateway.
• A própria porta de ligação pode ser dividida em vários tipos, como a porta de ligação ERC20 padrão, a porta de ligação genérica personalizada, a porta de ligação personalizada, etc., para resolver problemas de ligação 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.

WETH é um equivalente ERC20 de ETH. Uma vez que o éter serve como moeda principal, muitas funcionalidades complexas nas dApps são impossíveis de alcançar diretamente. Por conseguinte, é necessário um equivalente ERC20 como o WETH. Ao depositar algum ETH no contrato WETH, fica bloqueado 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 manterão sempre um rácio de 1:1.

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

• É impossível desdobrar WETH em ETH em L2 porque não existe ETH correspondente para bloquear 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 podem ser desembrulhados em ETH em L1 porque os contratos WETH em L1 e L2 não são "simétricos" 。

É evidente que isto viola os princípios de conceção do WETH. Portanto, ao cruzar a cadeia cruzada WETH, seja depositando ou retirando, é necessário desembrulhá-lo em ETH primeiro, depois cruzá-lo e envolvê-lo novamente em WETH. É aqui que o WETH Gateway entra em ação.

Da mesma forma, outros tokens com lógicas mais complexas requerem Gateways mais sofisticadas e cuidadosamente concebidas para funcionarem corretamente num ambiente de cadeia cruzada. O Gateway personalizado da Arbitrum herda a lógica de comunicação cross-chain de um Gateway padrão e permite que os desenvolvedores personalizem comportamentos cross-chain relacionados a lógicas de token, satisfazendo a maioria dos requisitos.

Caixa de entrada atrasada

A contrapartida da SequencerInbox, também conhecida como caixa rápida, é a Inbox (oficialmente denominada Delayed Inbox). Porque é que faz uma distinção entre caixas rápidas e caixas atrasadas? Porque o fast box foi especificamente concebido para receber lotes de transacções L2 publicadas pelo sequenciador, e quaisquer transacçõ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 é tratar o comportamento de depósito de L1 para L2. Os utilizadores iniciam depósitos através da caixa lenta, que o sequenciador reflecte depois em L2. Eventualmente, este registo de depósito será incluído na sequência de transacções L2 pelo sequenciador e enviado para o contrato de caixa rápido, o SequencerInbox.

Neste cenário, não é adequado que os utilizadores enviem diretamente transacções de depósito para a caixa rápida porque as transacções enviadas para a SequencerInbox interfeririam com a sequência normal de transacções do nível 2, afectando assim o funcionamento do sequenciador.

O segundo papel da caixa atrasada é a resistência à censura. As transacções diretamente submetidas ao contrato de caixa atrasado são normalmente agregadas ao caixa rápido no prazo de 10 minutos pelo sequenciador. No entanto, se o sequenciador ignorar maliciosamente o seu pedido, a caixa de atraso tem uma função de inclusão forçada:

Se uma transação for submetida à Caixa de entrada atrasada e permanecer não agregada na sequência de transacções pelo sequenciador após 24 horas, os utilizadores podem ativar manualmente a função de inclusão forçada no nível 1. Esta ação força os pedidos de transação ignorados pelo sequenciador a serem agregados na caixa rápida, a SequencerInbox, e subsequentemente a serem detectados por todos os nós do Arbitrum One, sendo assim incluídos à força na sequência de transação da camada 2.

Como mencionámos anteriormente, os dados na caixa rápida representam a entidade de dados históricos de L2. Por conseguinte, em casos de censura maliciosa, as transacções podem ser finalmente incluídas no livro-razão L2 através da utilização da caixa atrasada, abrangendo cenários como os levantamentos forçados da camada 2.

Daqui se conclui que o sequenciador não pode, em última análise, censurar permanentemente as transacções em qualquer direção ou camada.

As principais funções da caixa lenta Inbox são as seguintes

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

No entanto, é importante notar que a função forceInclusion() reside efetivamente no contrato da caixa rápida. Para maior clareza, discutimo-la aqui juntamente com as funções da caixa lenta.

Caixa de saída

A Outbox está apenas relacionada com os levantamentos e pode ser entendida como um sistema de registo e gestão dos comportamentos de levantamento:

• Sabemos que os levantamentos na ponte oficial do Arbitrum precisam de esperar cerca de 7 dias para que o período de desafio termine, e o levantamento só pode ser implementado depois de o Bloco de Rollup ser finalizado. Após o fim do período de desafio, o utilizador submete a prova de Merkle correspondente ao contrato Outbox na Layer1, que comunica depois com contratos para outras funções (como desbloquear activos bloqueados noutros contratos) e, finalmente, conclui o levantamento.
• O contrato OutBox regista quais as mensagens L2 para L1 da cadeia cruzada que foram processadas para evitar que alguém submeta repetidamente pedidos de levantamento executados. Consegue-o através de um mapeamento denominado spent, que associa os índices spent dos pedidos de levantamento às informações correspondentes. Se mapping[spentIndex] != bytes32(0), indica que o pedido já foi retirado. O princípio é semelhante ao de um nonce de contador de transacções, utilizado para evitar ataques de repetição.

De seguida, explicar-lhe-emos o processo de depósito e levantamento utilizando a ETH como exemplo. O processo para os tokens ERC20 é semelhante, com a adição de um Gateway, mas não entraremos em detalhes sobre isso aqui.

Depósito de ETH

1. O utilizador chama a função depositETH() da Caixa de entrada atrasada.
2. Esta função chama então bridge.enqueueDelayedMessage(), que regista a mensagem no contrato de ponte e envia a ETH para o contrato de ponte. Todos os fundos ETH depositados são mantidos no contrato-ponte, actuando como um endereço de depósito.
3. O sequenciador monitoriza a mensagem de depósito na Delayed Inbox e reflecte a operação de depósito na base de dados L2. Os utilizadores podem ver os seus activos depositados na rede L2.
4. O sequenciador inclui o registo de depósito num lote de transacções e submete-o ao contrato Fast Inbox em L1.

Retirada de ETH

1. O utilizador chama a função withdrawEth() do contrato ArbSys em L2 e queima a quantidade correspondente de ETH em L2.

2. O sequenciador envia o pedido de levantamento para a caixa rápida.

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

4. Depois de o bloco de rollup passar o período de desafio e ser confirmado, o utilizador pode chamar a função Outbox.execute Transaction() em L1 para provar que os parâmetros são dados pelo contrato ArbSys acima mencionado.

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

Levantamentos rápidos

A utilização da ponte oficial de Rollup otimista implica esperar por um período de desafio. Para contornar este problema, pode utilizar uma ponte privada de cadeia cruzada de terceiros:

• Troca atómica de trocas: Nesta abordagem, os activos são trocados entre as partes dentro das respectivas cadeias, e é atómica, o que significa que se uma parte fornecer a pré-imagem, ambas as partes podem obter os activos correspondentes. No entanto, a liquidez é relativamente escassa, o que exige a procura de contrapartes entre pares.
• Ponte de cadeia cruzada baseada em testemunhas: A maioria dos tipos de pontes de cadeia cruzada enquadra-se nesta categoria. Os utilizadores submetem os seus pedidos de levantamento, especificando o destino como o operador ou a pool de liquidez da ponte de terceiros. Quando a testemunha descobre que a transação entre cadeias foi submetida ao contrato Fast Inbox em L1, pode transferir fundos diretamente para o utilizador em L1. Essencialmente, este método utiliza outro sistema de consenso para monitorizar a camada 2 e efetuar operações com base nos dados enviados para a camada 1. No entanto, o nível de segurança neste modo é inferior ao da ponte oficial de rollup.

Forçar a retirada

A função forceInclusion() é utilizada para contrariar a censura do sequenciador. Pode ser aplicado a quaisquer transacções locais L2, transacções L1 para L2 e transacções L2 para L1. Uma vez que a censura maliciosa do sequenciador afecta significativamente a experiência da transação, optamos frequentemente por nos retirarmos do L2. Abaixo está um exemplo de uso de forceInclusion() para forçar retiradas:

No contexto das retiradas de ETH, apenas os passos 1 e 2 envolvem censura do sequenciador. Por conseguinte, só precisamos de alterar estas duas etapas:

• Chame inbox.sendL2Message() no contrato Delayed Inbox em L1, com os parâmetros necessários para chamar withdrawEth() em L2. Esta mensagem é partilhada 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 Fast Inbox para forçar a inclusão. O contrato Fast Inbox verifica se existe uma mensagem correspondente na ponte.

Por fim, os utilizadores podem fazer levantamentos da Caixa de saída e os restantes passos são os mesmos que num processo de levantamento normal.

Além disso, existem tutoriais detalhados no repositório arbitrum-tutorials que orientam os utilizadores sobre como realizar transacções locais L2 e transacções L2 para L1 utilizando forceInclusion() através do SDK do Arb.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de [Geek Web3], Todos os direitos de autor pertencem ao autor original[Luo Benben, antigo embaixador técnico da Arbitrum, colaborador da geek web3]]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.