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

Texto principal: Em artigos anteriores, mencionámos que o contrato da Caixa de Entrada do Sequenciador foi especificamente concebido para receber lotes de dados de transações publicados pelo sequenciador na Camada 1. Ao mesmo tempo, salientamos que a Caixa de Entrada do Sequenciador também é referida como a “caixa rápida” e, em contraste, existe a “caixa lenta” ou Caixa de entrada atrasada (referida como Caixa de entrada). Abaixo, fornecer-lhe-emos uma interpretação detalhada dos componentes relacionados com a transmissão 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 para L2 (depósito) e transações de L2 para L1 (retirada). É importante notar que os termos “depósito” e “retirada” aqui podem não envolver necessariamente a transferência de ativos entre cadeias; podem referir-se à passagem de mensagens sem transferir diretamente ativos. Portanto, estes termos representam apenas as duas direções das ações relacionadas com a cadeia cruzada.

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

Além disso, quando falamos de ações entre cadeias, normalmente refere-se ao cruzamento entre duas redes totalmente não relacionadas usando uma ponte de cadeia cruzada num modelo federado. A segurança dessas operações entre cadeias depende do operador da ponte entre cadeias e, historicamente, os incidentes de roubo têm sido frequentes em pontes de cadeia cruzada baseadas em testemunhas.

Por outro lado, as ações de cadeia cruzada entre o Rollup e a rede principal ETH são fundamentalmente diferentes dos processos de cadeia cruzada acima mencionados. Isto porque o estado da Camada2 é determinado pelos dados registados na Camada1. Desde que use a ponte Rollup cross-chain oficial, é estruturalmente segura nas suas operações.

Isto destaca a essência do Rollup, que, do ponto de vista do utilizador, aparece como uma cadeia independente, mas na realidade, a chamada “Camada2” é apenas uma janela de visualização rápida aberta pelo Rollup aos utilizadores, e a sua verdadeira estrutura em cadeia ainda está registada na Camada1. Portanto, podemos considerar L2 como meia cadeia ou “uma cadeia criada na Camada 1".

Retentáveis

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

Os bilhetes que podem ser repetidos são ferramentas fundamentais utilizadas na ponte oficial do Arbitrum durante os depósitos, aplicáveis aos depósitos ETH e ERC20. O ciclo de vida consiste em três etapas:

1. Enviar o bilhete no L1: Utilize o método 'createRetryableTicket () 'no contrato Caixa de entrada atrasada para criar um bilhete de depósito e enviá-lo.
2. Resgate automático no L2: Na maioria dos casos, o sequenciador pode resgatar automaticamente o bilhete para o utilizador sem exigir ações manuais adicionais.
3. Resgate manual no L2: Em certos casos extremos, como um aumento súbito nos preços do gás no L2, se o gás pré-pago no bilhete for insuficiente, o resgate automático não pode ocorrer. Neste cenário, é necessária a intervenção manual do utilizador. É importante notar que se o resgate automático falhar, o utilizador precisa de resgatar manualmente o bilhete no prazo de 7 dias; caso contrário, o bilhete será eliminado (resultando em perda permanente de fundos) ou o utilizador terá de pagar uma certa taxa para renovar o armazenamento do bilhete.

Além disso, relativamente ao processo de levantamento na ponte oficial do Arbitrum, embora exista uma certa semelhança simétrica no processo em comparação com os depósitos, não existe o conceito de bilhetes repetitivos. Isso pode ser entendido da perspectiva do próprio protocolo Rollup, e algumas diferenças podem ser destacadas:

• Não há resgate automático durante o processo de retirada porque o EVM não possui temporizadores ou automação. No L2, o resgate automático pode ser implementado e é facilitado pelo sequenciador. Portanto, os utilizadores da L1 precisam de interagir manualmente com o contrato Outbox para reclamar os seus ativos.
• Não há problema de vencimento do bilhete durante os levantamentos. Enquanto o período de desafio tiver passado, os utilizadores podem reclamar os seus ativos a qualquer momento.

Gateway de cadeia cruzada para ativos ERC-20

A cadeia cruzada de ativos ERC-20 é complexa. Podemos pensar em várias perguntas:

• como implementar um token implantado em L1 em L2?
• O seu contrato correspondente L2 precisa de ser implantado manualmente com antecedência, ou o sistema pode implementar automaticamente contratos de ativos para tokens que cruzaram mas ainda não implantaram um contrato?
• Para ativos ERC-20 em L1, qual é o endereço do contrato correspondente no L2? Deve ser consistente com L1?
• Como os tokens emitidos nativamente no L2 podem ser cruzados em cadeia para L1?
• Como podem os tokens com funções especiais, como rebase tokens com quantidades ajustáveis e tokens com juros de crescimento próprio, ser cruzados?

Não vamos responder a todas estas perguntas porque são demasiado complexas para se desenrolar. Estas perguntas são usadas apenas para ilustrar a complexidade da cadeia cruzada 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 contorno.

O Arbitrum utiliza o sistema Gateway para resolver a maioria dos problemas de aderência do ERC20 cross-chain. Tem as seguintes características:

• Os componentes do gateway aparecem em pares em L1 e L2.
• O Gateway Router é responsável por manter o mapeamento de endereços entre o Token L1<->Token L2. Além disso, o mapeamento entre algum token<->algum gateway.
• O próprio Gateway 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 usar a cadeia cruzada WETH relativamente simples como exemplo para ilustrar a necessidade de personalizar o gateway.

WETH é um equivalente ERC20 da ETH. Como moeda principal, o Ether não pode implementar funções complexas em muitos DApps, pelo que é 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, o WETH também pode ser queimado e o ETH pode ser retirado. Obviamente, o rácio de WETH circulante e ETH bloqueado é sempre 1:1.

Se agora formos diretamente de cadeia cruzada WETH para L2, encontraremos alguns problemas estranhos:

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

Obviamente, isso viola os princípios de design da WETH. Portanto, quando o WETH é de cadeia cruzada, seja depósito ou retirada, ele precisa ser desembrulhado em ETH primeiro, 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 exigem um Gateway mais complexo e cuidadosamente projetado para funcionar corretamente num ambiente de cadeia cruzada. O Gateway personalizado do Arbitrum herda a lógica de comunicação entre cadeias do Gateway comum e permite aos programadores personalizar o comportamento de cadeia cruzada relacionado com a lógica de token, que pode satisfazer a maioria das necessidades.

Caixa de entrada atrasada

A contrapartida da caixa de entrada rápida, conhecida como Sequencer Inbox, é a caixa de entrada lenta (totalmente denominada Caixa de entrada atrasada). Porquê diferenciar entre rápido e lento? Isto 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 para L2. Os utilizadores iniciam depósitos através da caixa de entrada lenta e, uma vez que o sequenciador observa isso, reflete no L2. Eventualmente, este registo de depósito é incluído na sequência de transações L2 pelo sequenciador e submetido ao contrato de caixa de entrada rápida (Caixa de entrada do sequenciador).

Neste cenário, não é apropriado que os utilizadores enviem diretamente transações de depósito para a caixa de entrada rápida (Caixa de Entrada do Sequenciador) porque as transações submetidas à caixa de entrada rápida podem interromper o pedido normal da transação na Camada2, afetando assim a operação do sequenciador.

A segunda função da caixa de entrada lenta é resistente à censura. As transações submetidas diretamente ao contrato de caixa de entrada lenta são geralmente agregadas na caixa de entrada rápida dentro de 10 minutos pelo sequenciador. No entanto, se o sequenciador ignorar maliciosamente o seu pedido, a caixa de entrada lenta tem uma funcionalidade de inclusão forçada:

Se uma transação for submetida à Caixa de Entrada Atrasada e, após 24 horas, permanecer não incorporada na sequência de transações pelo sequenciador, os utilizadores podem acionar manualmente a função de inclusão de força 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, serão detectados por todos os nós do Arbitrum One e incluídos à força na sequência de transações da Camada 2.

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

A partir disso, pode ser visto que para qualquer direção e nível de transações, 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 comparação com DepositeTh (), permitindo especificações como o endereço de recebimento em L2 após o depósito.
• forceInclusion (): Esta função, a funcionalidade 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 cumpridas, inclui a mensagem à força.

No entanto, é importante notar que a função de inclusão de força está realmente localizada no contrato da caixa de entrada rápida. Para facilitar a compreensão, explicámo-lo em conjunto com a caixa de entrada lenta.

Caixa de saída

Outbox está apenas relacionado com levantamentos e pode ser entendido como um sistema de registo e gestão de comportamentos de retirada:

• Sabemos que as retiradas na ponte oficial do Arbitrum precisam de esperar cerca de 7 dias para que o período de desafio termine, e a retirada só pode ser implementada após o bloco de rollup estar finalizado. Após o término do período de contestação, o utilizador submete a Merkle Proof correspondente ao contrato Outbox na Camada1, que depois comunica com os contratos para outras funções (como desbloquear ativos bloqueados noutros contratos), e finalmente conclui a retirada.
• O contrato OutBox registará quais mensagens de cadeia cruzada de L2 a L1 foram processadas para impedir que alguém envie repetidamente pedidos de levantamento executados. Regista a correspondência entre o índice de gastos e a informação do pedido de levantamento usando 'mapping (uint256 = > bytes32) public spent'. Se estiver a mapear [SpenTIndex]! = bytes32 (0), o pedido foi retirado. O princípio é semelhante ao contador de transações Nonce para prevenir ataques de repetição.

Abaixo, 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 em pormenor.

Depósito ETH

1. O utilizador chama a função DepositeTH () da caixa lenta.

2. Esta função continuará a chamar 'Bridge.enQueueDelayedMessage () ', registar a mensagem no contrato da ponte e enviar ETH para o contrato da ponte. Todos os fundos de depósito ETH são mantidos no contrato bridge, o que equivale a um endereço de depósito.

3. O sequenciador monitoriza as mensagens de depósito na caixa lenta e reflete a operação de depósito na base de dados L2. Os utilizadores podem ver os ativos que depositaram na rede L2.

4. O sequenciador inclui o registo de depósito no lote de transações e envia-o para o contrato de caixa rápida em L1.

Retirada ETH

1. O utilizador chama a função de levantamento ETH () do contrato ArbSys em L2, e o número correspondente de ET é queimado em L2.

2. O sequenciador envia o pedido de levantamento para a caixa expressa.

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

4. Depois que o bloco de rollup passar pelo período de desafio que também está 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 mencionado acima.

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

Levantamento rápido de dinheiro

Ao usar a ponte oficial Optimistic Rollup para sacar dinheiro, haverá um problema de esperar pelo período de desafio. Podemos usar uma ponte de cadeia cruzada privada de terceiros para remover este problema:

• Troca de fechaduras atómicas. Este método apenas troca ativos entre as duas partes dentro das respetivas cadeias e é atómico. Desde que uma das partes forneça Pré-imagem, ambas as partes terão definitivamente os ativos que merecem. Mas o problema é que a liquidez é relativamente escassa e precisa encontrar contrapartes com um método peer-to-peer.f
• Testemunhas atravessam a ponte das cadeias. Os tipos gerais de pontes de cadeia cruzada são pontes de testemunhas. Os utilizadores enviam os seus próprios pedidos de levantamento e o destino da retirada aponta para o 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 L1, ele pode transferir dinheiro diretamente para o utilizador do lado L1. Esta abordagem utiliza essencialmente outro sistema de consenso para monitorizar a Camada 2 e operar com base nos dados que submeteu à Camada 1.O problema é que o nível de segurança neste modo não é tão elevado como o da ponte rollup oficial. \

Retirada forçada

A função force Inclusion () é 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 retirar dinheiro e deixar o 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 os passos 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 levanteTh () em L2. Esta mensagem será partilhada com o contrato da ponte no L1.
• Após um período de espera de inclusão forçada de 24 horas, forçar a Inclusão () na caixa rápida é chamada para realizar a inclusão forçada. O contrato de caixa rápida irá verificar se há uma mensagem correspondente na ponte.

Os utilizadores finais podem retirar dinheiro no Outbox, e o resto dos passos são os mesmos que os levantamentos normais.

Além disso, existem também tutoriais detalhados sobre a utilização do SDK Arb em tutoriais de arbitragem para orientar os utilizadores sobre como realizar transações locais L2 e transações L2 a L1 através da função forceInclusion ().

Isenção de responsabilidade：

1. Este artigo foi reimpresso de [Web3]. Todos os direitos de autor pertencem ao autor original [Web3]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.