No artigo anterior, “Estrutura dos componentes do Arbitrum interpretada pelo ex-embaixador técnico do Arbitrum (Parte 1)”, introduzimos as funções dos principais componentes do Arbitrum, incluindo o sequenciador, validador, contrato de caixa de entrada do sequenciador, bloco rollup e a função de provas de fraude não interativas. No artigo de hoje, vamos nos concentrar em explicar os componentes relacionados à passagem de mensagens entre cadeias e à entrada para transações anticensura nos componentes principais do Arbitrum.

Texto principal: Em artigos anteriores, mencionamos que o contrato Sequencer Inbox é projetado especificamente para receber lotes de dados de transações publicados pelo sequenciador na Camada 1. Ao mesmo tempo, apontamos que a Caixa de Entrada do Sequenciador também é chamada de “caixa rápida” e, em contraste, existe a “caixa lenta” ou Caixa de Entrada Atrasada (conhecida como Caixa de Entrada). Abaixo, forneceremos uma interpretação detalhada dos componentes relacionados à passagem de mensagens entre cadeias, incluindo a Caixa de Entrada Atrasada.

O princípio da cadeia cruzada e da ponte

As transações entre cadeias podem ser divididas em transações de L1 a L2 (depósito) e transações de L2 a L1 (saque). É importante notar que os termos “depósito” e “retirada” aqui podem não envolver necessariamente a transferência de ativos entre cadeias; eles podem se referir à passagem de mensagens sem transferir ativos diretamente. Portanto, estes termos representam apenas as duas direções de ações relacionadas entre cadeias.

Em comparação com as transações L2 puras, as transações cross-chain envolvem a troca de informações entre dois sistemas diferentes, L1 e L2, tornando o processo mais complexo.

Além disso, quando falamos sobre ações entre cadeias, geralmente nos referimos ao cruzamento entre duas redes totalmente não relacionadas usando uma ponte entre cadeias em um modelo federado. A segurança de tais operações entre cadeias depende do operador da ponte entre cadeias e, historicamente, os incidentes de roubo têm sido frequentes em pontes entre cadeias baseadas em testemunhas.

Por outro lado, as ações cross-chain entre Rollup e a rede principal ETH são fundamentalmente diferentes dos processos cross-chain acima mencionados. Isso ocorre porque o estado da Camada2 é determinado pelos dados registrados na Camada1. Contanto que você use a ponte cross-chain Rollup oficial, ela estará estruturalmente segura em suas operações.

Isso destaca a essência do Rollup, que, do ponto de vista do usuário, aparece como uma cadeia independente, mas na realidade, a chamada “Layer2” é apenas uma janela de exibição rápida aberta pelo Rollup para os usuários, e sua verdadeira estrutura semelhante a uma cadeia ainda está gravado na Camada1. Portanto, podemos considerar L2 como meia cadeia ou “uma cadeia criada na Camada1”.

Novas tentativas

Observe que as transações entre cadeias são assíncronas e não atômicas. Ao contrário das transações em uma única cadeia, concluir uma transação e confirmar o resultado após uma transação em uma cadeia não é possível em transações entre cadeias. Também não há garantia de que algo específico acontecerá do outro lado em determinado momento. Portanto, as transações entre cadeias podem falhar devido a alguns problemas leves, mas com o uso de técnicas adequadas, como tickets repetíveis, problemas difíceis, como a retenção de fundos, não ocorrerão.

Os tickets retentáveis são ferramentas fundamentais utilizadas na ponte oficial da Arbitrum durante os depósitos, aplicáveis tanto aos depósitos ETH quanto ao ERC20. O ciclo de vida consiste em três etapas:

1. Enviando o ticket em L1: Use o método 'createRetryableTicket()' no contrato Delayed Inbox para criar um ticket de depósito e enviá-lo.
2. Resgate automático em L2: Na maioria dos casos, o sequenciador pode resgatar automaticamente o ticket para o usuário sem exigir ações manuais adicionais.
3. Resgate manual no L2: Em certos casos extremos, como um aumento repentino no preço do gás no L2, se o gás pré-pago no bilhete for insuficiente, o resgate automático não poderá ocorrer. Neste cenário é necessária a intervenção manual do usuário. É importante ressaltar que caso o resgate automático falhe, o usuário deverá resgatar manualmente o bilhete em até 7 dias; caso contrário, o bilhete será excluído (resultando em perda permanente de fundos) ou o usuário precisará pagar uma determinada taxa para renovar o armazenamento do bilhete.

Além disso, no que diz respeito ao processo de saque na ponte oficial da Arbitrum, embora haja uma certa semelhança simétrica no processo em relação aos depósitos, não existe o conceito de bilhetes retentáveis. Isso pode ser entendido sob a perspectiva do próprio protocolo Rollup, e algumas diferenças podem ser destacadas:

• Não há resgate automático durante o processo de saque porque o EVM não possui temporizadores ou automação. Em L2, o resgate automático pode ser implementado e é facilitado pelo sequenciador. Portanto, os usuários em L1 precisam interagir manualmente com o contrato Outbox para reivindicar a devolução de seus ativos.
• Não há problema de vencimento do ticket durante os saques. Enquanto o período de desafio tiver passado, os usuários poderão reivindicar seus ativos a qualquer momento.

Gateway Cross-Chain para Ativos ERC-20

O encadeamento cruzado de ativos ERC-20 é complexo. Podemos pensar em várias questões:

• como implantar um token implantado em L1 em L2?
• Seu 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 os tokens emitidos nativamente em L2 podem ser encadeados em 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 escalonamento usam soluções de lista branca e lista manual para evitar vários problemas complexos e condições de limite.

Arbitrum usa o sistema Gateway para resolver a maioria dos problemas persistentes da cadeia cruzada ERC20. Possui os seguintes recursos:

• Os componentes do gateway aparecem em pares em L1 e L2.
• O Gateway Router é responsável por manter o mapeamento de endereços entre Token L1<->Token L2. Além disso, o mapeamento entre algum token<->algum gateway.
• O gateway em si pode ser dividido em gateway ERC20 padrão, gateway personalizado genérico, 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 queimado e o ETH pode ser retirado. Obviamente, a proporção entre WETH circulante e ETH bloqueado é sempre de 1:1.

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

• É impossível desembrulhar WETH em ETH em L2 porque não há ETH correspondente para travar 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. Portanto, quando o WETH é encadeado de forma cruzada, seja para depósito ou retirada, ele precisa primeiro ser desembrulhado em ETH, depois cruzado para o outro lado e depois embrulhado em WETH. Este é o papel 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

A contrapartida da caixa de entrada rápida, conhecida como Caixa de entrada do sequenciador, é a caixa de entrada lenta (totalmente denominada Caixa de entrada atrasada). Por que diferenciar entre rápido e lento? Isso ocorre porque a caixa de entrada rápida é dedicada a receber lotes de transações L2 publicadas pelo sequenciador, e quaisquer transações não pré-processadas pelo sequenciador dentro da rede L2 não devem aparecer no contrato da caixa de entrada rápida.

A primeira função da caixa de entrada lenta é lidar com o processo de depósito de L1 a L2. Os usuários iniciam os depósitos por meio da caixa de entrada lenta e, uma vez que o sequenciador observa isso, isso reflete no L2. Eventualmente, esse registro de depósito é incluído na sequência de transação L2 pelo sequenciador e submetido ao contrato de caixa de entrada rápida (Sequencer Inbox).

Nesse cenário, não é apropriado que os usuários enviem transações de depósito diretamente para a caixa de entrada rápida (Caixa de entrada do sequenciador) porque as transações enviadas para a caixa de entrada rápida podem interromper a ordem normal da transação na Camada 2, afetando assim a operação do sequenciador.

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

Se uma transação for enviada para a Caixa de Entrada Atrasada e, após 24 horas, permanecer não incorporada na sequência de transações pelo sequenciador, os usuários podem acionar manualmente a função de inclusão forçada na Camada1. Esta ação obriga as transações ignoradas pelo sequenciador a serem agregadas à força na caixa de entrada rápida (Caixa de entrada do sequenciador). Posteriormente, eles serão detectados por todos os nós do Arbitrum One e incluídos à força na sequência de transações da Camada2.

Acabamos de mencionar que os dados na caixa de entrada rápida representam a entidade de dados históricos de L2. Portanto, em casos de censura maliciosa, o uso da caixa de entrada lenta permite que instruções de transação sejam eventualmente incluídas no razão L2, abrangendo cenários como retiradas forçadas para escapar da Camada2.

A partir disso, pode-se ver que, para qualquer direção e nível de transação, o sequenciador, em última análise, não pode censurá-lo permanentemente.

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

• depositETH(): A função mais simples para depositar ETH.
• createRetryableTicket(): Usado para depositar ETH, ERC20 e mensagens. Oferece maior flexibilidade em relação ao depositETH(), permitindo especificações como o endereço de recebimento em L2 após o depósito.
• forceInclusion(): Esta função, o recurso de inclusão forçada, pode ser chamada por qualquer pessoa. A função verifica se uma transação submetida ao contrato de caixa de entrada lenta não foi processada após 24 horas. Se as condições forem atendidas, a mensagem será incluída à força.

No entanto, é importante observar que a função de inclusão forçada está, na verdade, localizada no contrato da caixa de entrada rápida. Para facilitar o entendimento, explicamos junto com a caixa de entrada lenta.

Caixa de fora

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

• 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ó poderá ser implementado após a finalização do Rollup Block. 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. Ele registra a correspondência entre o índice de gastos e as informações da solicitação de saque usando 'mapping(uint256 => bytes32) gastos públicos'. Se mapeamento[spentIndex] != bytes32(0), a solicitação foi retirada. O princípio é semelhante ao contador de transações Nonce para prevenir 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 ERC20 e ETH é que o primeiro usa Gateway. Não vamos explicar isso 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()', grave a mensagem no contrato de ponte e envie ETH para o contrato de ponte. Todos os fundos de depósito em ETH são mantidos no contrato ponte, que equivale a um endereço de depósito.

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

4. O sequenciador inclui o registro de depósito no lote de transação 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, e o número correspondente de ET é queimado em L2.

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

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

4. Após o Rollup Block passar pelo período de desafio que também é confirmado, o usuário pode chamar a função Outbox.execute Transaction() em L1 para comprovar 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 será desbloqueada e enviada ao usuário.

Retirada rápida de dinheiro

Ao usar a ponte oficial do Optimistic Rollup para sacar dinheiro, haverá o problema de aguardar o período de desafio. Podemos usar uma ponte cross-chain privada de terceiros para remover este problema:

• Troca de bloqueio atômico. Este método apenas troca ativos entre as duas partes dentro de suas respectivas cadeias e é atômico. Contanto que uma das partes forneça a Pré-imagem, ambas as partes certamente receberão os ativos que merecem. Mas o problema é que a liquidez é relativamente escassa e é necessário encontrar contrapartes com um método peer-to-peer.F
• Testemunhas atravessam a ponte de corrente. Os 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 fast box L1, ela poderá transferir dinheiro diretamente para o usuário no 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 nível de segurança neste modo não é tão alto quanto o da ponte Rollup oficial. \

Retirada forçada

A função force Inclusão() é usada para resistir à censura 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 censura maliciosa do sequenciador afeta seriamente a experiência da transação. Na maioria dos casos, optaremos por sacar dinheiro e sair do L2. Portanto, o seguinte usa a retirada forçada como exemplo para introduzir o uso de forceInclusion.

Olhando para trás, para as etapas de retirada da ETH, apenas as etapas 1 e 2 envolvem censura do sequenciador, portanto, apenas estas duas etapas precisam ser alteradas:

• Ao chamar 'inbox.sendL2Message()' no contrato de caixa lenta 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 um período de espera de inclusão forçada de 24 horas, force Inclusão() na caixa rápida é chamada para realizar a inclusão forçada. O contrato fast box verificará se há uma mensagem correspondente na ponte.

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

Além disso, também há tutoriais detalhados sobre como usar o Arb SDK em tutoriais de arbitragem para orientar os usuários sobre como realizar transações locais L2 e transações L2 para L1 por meio da função forceInclusion().

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [极客 Web3]. Todos os direitos autorais pertencem ao autor original [极客 Web3]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho 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.