Ainda ontem, um evento chocante ocorreu: a Linea, a solução Ethereum Camada 2 desenvolvida pela Consensys, controladora da Metamask, foi desativada proativamente. A razão oficial dada foi para mitigar o impacto do incidente de hacking Velocore. Este incidente inevitavelmente traz à mente um caso anterior em que a cadeia BSC (BNB Chain) também foi fechada sob coordenação oficial para minimizar as perdas de hackers. Esses eventos muitas vezes levam as pessoas a questionar os valores descentralizados que a Web3 defende.

A razão central por trás dos eventos mencionados reside na imperfeição da infraestrutura, especificamente sua falta de descentralização. Se um blockchain fosse suficientemente descentralizado, ele não deveria ser capaz de se desligar tão facilmente. Devido à estrutura única do Ethereum Camada 2, a maioria das soluções Camada 2 conta com sequenciadores centralizados. Apesar do crescente discurso sobre sequenciadores descentralizados nos últimos anos, dado o propósito e a estrutura do Camada 2, podemos supor que é improvável que Camada 2 sequenciadores alcancem altos níveis de descentralização. Na verdade, eles podem acabar sendo menos descentralizados do que a cadeia BSC. Se for esse o caso, o que pode ser feito? Por Camada 2, os riscos mais imediatos dos sequenciadores não descentralizados são a falta de resistência à censura e vivacidade. Se houver apenas algumas entidades processando transações (sequenciadores), elas têm poder absoluto sobre se devem atendê-lo ou não: elas podem recusar suas transações à vontade, deixando-o sem recurso. Abordar a questão resistência à censura em Camada 2 é claramente um tópico importante. Ao longo dos últimos anos, várias soluções Ethereum Camada 2 propuseram diferentes abordagens para enfrentar esta questão. Por exemplo, Loopring, Degate e StarkEx introduziram funções de retirada forçada e escape hatch, enquanto Arbitrum e outros Rollups Otimistas implementaram recursos de Inclusão de Força. Esses mecanismos podem impor verificações aos sequenciadores para evitar a recusa arbitrária de transações do usuário. No artigo de hoje, NIC Lin, da Taipei Ethereum Association, compartilha sua experiência em primeira mão, experimentando os recursos de transação resistentes à censura de quatro grandes Rollups e fornecendo uma análise aprofundada do mecanismo de Inclusão de Força, com foco no fluxo de trabalho e métodos operacionais. Esta análise é especialmente valiosa para a comunidade Ethereum e grandes detentores de ativos.

Censura de transações e inclusão forçada

A censura resistência em transações é crucial para qualquer blockchain. Se um blockchain pode arbitrariamente censurar e rejeitar transações de usuários, não é diferente de um servidor Web2. O resistência à censura transaccional da Ethereum é actualmente assegurado pelos seus numerosos validadores. Se alguém quiser censurar a transação de Bob e impedir que ela seja incluída no blockchain, terá que subornar a maioria dos validadores da rede ou enviar spam à rede com transações de lixo que têm taxas mais altas do que as do Bob, ocupando assim o espaço do bloco. Ambos os métodos são extremamente dispendiosos.

Nota: Na arquitetura atual do Ethereum Proposer-Builder Separation (PBS), o custo de censurar transações é significativamente reduzido. Por exemplo, você pode observar a proporção de blocos que cumprem a censura do OFAC às transações do Tornado Cash. A resistência à censura atual depende de validadores e retransmissores independentes que estão fora da jurisdição do OFAC e de outras entidades governamentais.

Mas e os Rollups? Os pacotes cumulativos não exigem um grande número de validadores para garantir a segurança. Mesmo que um Rollup tenha apenas uma entidade centralizada (Sequencer) produzindo blocos, ele permanece tão seguro quanto a Camada 1 (L1). No entanto, segurança e resistência à censura são duas questões diferentes. Um Rollup, embora seja tão seguro quanto Ethereum, ainda pode censurar qualquer transação do usuário se tiver apenas um único sequenciador centralizado.

O Sequencer pode se recusar a processar a transação de um usuário, resultando no bloqueio dos fundos do usuário e na impossibilidade de sair do Rollup.

Mecanismo de inclusão de força

Em vez de exigir que os Rollups tenham um grande número de sequenciadores descentralizados, é mais eficaz aproveitar diretamente o resistência à censura da Camada 1 (L1):

Como o sequenciador precisa empacotar dados de transação e enviá-los para o contrato de Rollup em L1, podemos adicionar um recurso no contrato que permite que os usuários insiram suas transações no contrato de Rollup. Esse mecanismo é conhecido como "Inclusão de Força". Por longo o sequenciador não possa censurar usuários no nível L1, ele não pode impedir que os usuários insiram transações à força em L1. Dessa forma, o Rollup pode herdar o resistência à censura de L1.

O Sequencer não pode revisar as transações L1 do usuário sem pagar um alto custo

Como as transações forçadas devem ser implementadas?

Se as transações puderem ser gravadas diretamente no contrato do Rollup por meio da Inclusão Forçada (o que significa que entrarão em vigor imediatamente), o estado do Rollup será alterado instantaneamente. Por exemplo, se Bob usar o mecanismo Force Inclusion para inserir uma transação que transfere 1000 DAI para Carol, e a transação entrar em vigor imediatamente, o saldo de Bob diminuiria em 1000 DAI, enquanto o saldo de Carol aumentaria em 1000 DAI no estado atualizado.

Se a Inclusão Forçada permitir que as transações sejam gravadas diretamente no contrato do Rollup e entrem em vigor imediatamente, o estado do Rollup será alterado instantaneamente. Se o sequenciador estiver coletando simultaneamente fora da cadeia transações e se preparando para enviar o próximo lote para o contrato de Rollup, ele poderá ser interrompido pela transação inserida à força de Bob que terá efeito imediato. Para evitar esse problema, os Rollups geralmente não permitem que as transações de Inclusão Forçada entrem em vigor imediatamente. Em vez disso, os usuários inicialmente inserem suas transações em uma fila de espera na L1, onde entram em um estado de "preparação". Quando o sequenciador empacota transações fora da cadeia para enviar ao contrato de Rollup, ele pode escolher se deseja incluir essas transações em fila. Se o sequenciador ignorar continuamente as transações no estado de "preparação", assim que o período de janela terminar, os usuários poderão inserir essas transações à força no contrato de Rollup. O sequenciador pode decidir quando "incluir incidentalmente" transações da fila de espera, mas ainda pode se recusar a processá-las. Se o sequenciador se recusar consistentemente, após um determinado período, qualquer pessoa poderá usar a função Forçar Inclusão para inserir à força as transações no contrato de Rollup. Em seguida, apresentaremos a implementação do mecanismo de Inclusão de Força em quatro Rollups proeminentes: Optimism, Arbitrum, StarkNet e zkSync.

O Sequencer pode escolher quando obter transações da fila de espera.

Os sequenciadores ainda podem se recusar a processar transações na fila de espera.

Se o sequenciador se recusar consistentemente a processar transações, após um determinado período, qualquer pessoa poderá usar a função Forçar Inclusão para inserir transações à força no contrato de Rollup. Em seguida, apresentaremos como o mecanismo de Inclusão de Força é implementado em quatro Rollups proeminentes: Optimism, Arbitrum, StarkNet e zkSync.

Mecanismo de Inclusão de Força do Otimismo

Primeiro, vamos discutir o processo de Depósito do Otimismo. Este processo de depósito envolve não apenas a transferência de fundos para o Optimism, mas também o envio de "mensagens de usuário para L2". Quando um nó L2 recebe uma mensagem recém-depositada, ele converte a mensagem em uma transação L2 e a executa, entregando-a ao destinatário especificado.

Mensagens de usuário depositadas de L1 a L2

Contrato L1CrossDomainMessenger

Quando um usuário deseja depósito ETH ou ERC-20 tokens no Optimism, ele interage com o contrato L1StandardBridge em L1 por meio de uma página da Web frontend, especificando o valor para depósito e o endereço L2 que receberá esses ativos. O contrato L1StandardBridge encaminha a mensagem para o contrato L1CrossDomainMessenger, que atua como o principal ponte de comunicação entre L1 e L2. O L1StandardBridge usa esse componente de comunicação para interagir com o L2StandardBridge em L2, determinando quem pode como tokens em L2 ou desbloquear tokens de L1. Os desenvolvedores que precisam criar contratos que interoperam e sincronizam estados entre L1 e L2 podem criá-los sobre o contrato L1CrossDomainMessenger.

Mensagens
de usuário transmitidas de L1 para L2 através do contrato CrossDomainMessenger

Nota: Em algumas imagens deste artigo, CrossDomainMessenger é escrito como CrossChainMessenger.

Contrato OptimismPortal

O contrato L1CrossDomainMessenger encaminha a mensagem para a camada mais baixa, o contrato OptimismPortal. Após o processamento da mensagem, o contrato do OptimismPortal emite um evento chamado TransactionDeposited, que inclui parâmetros como o "remetente", o "destinatário" e outros detalhes relevantes de execução. Os nós Optimism em L2 escutam este evento TransactionDeposited do contrato OptimismPortal e convertem os parâmetros do evento em uma transação L2. O iniciador desta transação será o "remetente" especificado no evento, o destinatário será o "destinatário" mencionado no evento, e outros detalhes da transação também serão derivados dos parâmetros do evento.

nós L2 convertem os parâmetros do evento Transaction Deposited emitido pelo OptimismPortal em uma transação L2.

Por exemplo, quando um usuário deposita 0,01 ETH através do contrato L1StandardBridge, a mensagem e ETH são transmitidas para o contrato OptimismPortal (endereço 0xbEb5... 06Ed). Alguns minutos depois, isso é convertido em uma transação L2: o remetente da mensagem é o contrato L1CrossDomainMessenger, o receptor é o contrato L2CrossDomainMessenger em L2 e o conteúdo da mensagem indica que o L1StandardBridge recebeu um ETH depósito 0,01 de Bob. Isso então aciona processos adicionais, como cunhagem ETH 0,01 para o L2StandardBridge, que posteriormente o transfere para Bob.

Como acioná-lo

Se você quiser incluir à força uma transação no contrato de Rollup da Optimism, seu objetivo é garantir que uma transação "iniciada e executada a partir de seu endereço L2 em L2" possa ser executada com sucesso. Para conseguir isso, você deve enviar a mensagem diretamente para o contrato do OptimismPortal usando seu endereço L2 (observe que o contrato do OptimismPortal está realmente em L1, mas o formato de endereço OP corresponde ao formato de endereço L1, então você pode chamar esse contrato usando um conta L1 com o mesmo endereço que seu conta L2). O "remetente" da transação L2 derivada do evento Transação Depositada emitido por este contrato será então seu conta L2, e o formato da transação será consistente com uma transação L2 padrão.

Na
transação L2 derivada do evento Transação Depositada, o próprio Bob será o iniciador, o receptor será o contrato Uniswap e incluirá o ETH especificado, como se Bob estivesse iniciando a transação L2 ele mesmo.

Para usar a função Force Inclusion do Optimism, você precisa chamar diretamente a função depositTransaction do contrato OptimismPortal e inserir os parâmetros da transação que deseja executar no L2. Conduzi um experimento simples de Inclusão de Força. O objetivo desta transação era realizar uma auto-transferência em L2 usando meu endereço (0xeDc1... 6909) e incluir uma mensagem dizendo "forçar a inclusão". Esta é a transação L1 que executei chamando a função depositTransaction através do contrato OptimismPortal. Como você pode ver no evento Transação Depositada que ele emitiu, tanto o remetente quanto o destinatário sou eu.

Os valores restantes na coluna Dados opacos codificam informações como "quanto ETH a pessoa que está chamando a função depositTransaction anexada", "quanto ETH o iniciador da transação L2 deseja enviar ao receptor", "GasLimit da transação L2" e "Dados para o receptor L2". Depois de decodificar essas informações, você obterá os seguintes detalhes: "quanto ETH a pessoa que está chamando o depositTransaction anexado": 0, porque eu não estou depositando ETH de L1 a L2; "quanto ETH o iniciador da transação L2 deseja enviar ao receptor": 5566 (nós); "Transação L2 GasLimit": 50000; "Dados para o receptor L2": 0x666f72636520696e636c7573696f6e, que é a codificação hexadecimal da cadeia de caracteres "forçar inclusão". Pouco depois, a transação L2 convertida apareceu: uma transação L2 onde eu transfiro 5566 nós para mim mesmo, com o campo Data contendo a string "force inclusion". Além disso, na penúltima linha da seção Outros Atributos, o TxnType (tipo de transação) é mostrado como transação do sistema 126 (Sistema), indicando que essa transação não foi iniciada por mim em L2, mas foi convertida do evento Deposited da transação L1.

Transação L2 convertida

Se você quiser chamar um contrato L2 através do Force Inclusion e enviar dados diferentes, basta preencher os parâmetros na função depositTransaction. Apenas lembre-se de usar o mesmo endereço L1 que seu conta L2 ao chamar a função depositTransaction. Dessa forma, quando o Evento Depositado for convertido em uma transação L2, o iniciador será seu conta L2. Janela do Sequenciador O nó L2 do Otimismo que converte o evento Transação Depositada em uma transação L2 é, na verdade, o Sequenciador. Como isso envolve a ordem de transações, somente o Sequencer pode decidir quando converter o evento em uma transação L2. Quando o Sequencer escuta o evento TransactionDeposited, ele não necessariamente converte o evento em uma transação L2 imediatamente; pode haver um atraso. A duração máxima desse atraso é chamada de Janela do Sequenciador. Atualmente, a janela do Sequencer na mainnet Optimism é de 24 horas. Isso significa que quando um usuário deposita dinheiro de L1 ou usa a Inclusão Forçada para uma transação, no pior cenário, ele será incluído no histórico de transações L2 após 24 horas.

Mecanismo de Inclusão de Força

do Arbitrum Em Otimismo, a operação L1 depósito aciona um evento Transação Depositada, e então é apenas uma questão de esperar que o Sequenciador inclua a operação. No entanto, no Arbitrum, as operações em L1 (como depositar fundos ou enviar mensagens para L2) são armazenadas em uma fila em L1, em vez de simplesmente emitir um evento. O Sequencer tem um período específico para incluir essas transações em fila no histórico de transações L2. Se o Sequencer não conseguir fazer isso dentro desse período de tempo, qualquer pessoa poderá intervir para concluir a inclusão em nome do Sequencer.

Arbitrum mantém uma Fila em um contrato L1. Se o Sequencer não conseguir processar as transações na Fila dentro de um determinado período, qualquer pessoa poderá incluir essas transações à força no histórico de transações L2. No projeto da Arbitrum, as operações em L1, como depósitos, devem passar pelo contrato de Caixa de Entrada Atrasada, onde, como o nome sugere, essas operações serão atrasadas antes de entrarem em vigor. Outro contrato, o Sequencer Inbox, é onde o Sequencer carrega diretamente as transações L2 para L1. Cada vez que o Sequencer carrega transações L2, ele também pode pegar algumas transações pendentes da Caixa de Entrada Atrasada e incluí-las no histórico de transações.

Quando o Sequencer grava novas transações, ele também pode incluir transações da DelayedInbox.

Projeto complexo e falta de materiais de referência

Se você consultar a documentação oficial do Arbitrum sobre o Sequencer e o Force Inclusion, encontrará uma explicação geral de como o Force Inclusion funciona, juntamente com alguns nomes de parâmetros e funções: Os usuários primeiro chamam a função sendUnsignedTransaction no contrato DelayedInbox. Se o Sequencer não incluí-lo dentro de cerca de 24 horas, os usuários podem chamar a função forceInclusion no contrato SequencerInbox. No entanto, a documentação oficial não fornece links para essas funções, então você mesmo precisa procurá-las no código do contrato. Quando você encontra a função sendUnsignedTransaction, percebe que você mesmo precisa preencher o valor nonce e o valor maxFeePerGas. De quem é a nonce? Qual rede é maxFeePerGas? Como você deve preenchê-lo corretamente? Não há documentos de referência, nem mesmo NatSpec. Você também encontrará muitas funções semelhantes no contrato de arbitragem: sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction. Não há documentos explicando as diferenças entre essas funções, como usá-las ou como preencher os parâmetros, nem mesmo o NatSpec.

Você tenta preencher os parâmetros e enviar a transação com uma abordagem de tentativa e erro, na esperança de encontrar o uso correto. No entanto, você descobre que todas essas funções se aplicam Endereço Aliasing ao seu endereço L1, fazendo com que o Remetente da transação no L2 seja um endereço completamente diferente, deixando seu endereço L2 inativo. Mais tarde, você acidentalmente se deparou com um resultado de pesquisa do Google revelando que a Arbitrum tem uma biblioteca de tutoriais com scripts demonstrando como enviar transações L2 de L1 (essencialmente forçar inclusão). O tutorial lista uma função não mencionada anteriormente: sendL2Message. Surpreendentemente, o parâmetro de mensagem necessário é, na verdade, uma transação L2 assinada usando um conta L2. Quem diria que a "mensagem enviada para L2 através da Force Inclusion" é, na verdade, uma "transação L2 assinada"? Além disso, não há documentos ou NatSpec explicando quando e como usar essa função.

Conclusão: Gerar manualmente uma transação forçada no Arbitrum é bastante complicado. Recomenda-se seguir o Tutorial oficial e usar o SDK do Arbitrum. Ao contrário de outros Rollups, o Arbitrum carece de documentação clara do desenvolvedor e anotações de código. Muitas funções carecem de explicações para seus propósitos e parâmetros, fazendo com que os desenvolvedores gastem muito mais tempo do que o esperado para integrá-las e usá-las. Também pedi ajuda no Arbitrum Discord, mas não obtive respostas satisfatórias. Ao perguntar no Discord, eles apenas me orientaram a olhar para o sendL2Message e não explicaram as funções de outros métodos (incluindo aqueles mencionados na documentação de Inclusão de Força como sendUnsignedTransaction), suas finalidades, como usá-los ou quando usá-los.

Mecanismo de ForceInclusion da StarkNet

Infelizmente, a StarkNet atualmente não tem um mecanismo de Inclusão de Força. Há apenas dois artigos no fórum oficial discutindo Censura e Inclusão Forçada. A razão para a incapacidade de provar transações com falha é que o sistema de prova de conhecimento zero da StarkNet não pode provar uma transação com falha, portanto, a inclusão forçada não pode ser permitida. Se alguém maliciosamente (ou involuntariamente) incluir uma transação falhada e não provável, a StarkNet ficaria presa: porque uma vez que a transação é incluída à força, o provador deve provar a transação falhada, mas não pode. Espera-se que a StarkNet introduza a capacidade de provar transações fracassadas na versão v0.15.0, após o que o mecanismo de Inclusão de Força deve ser implementado posteriormente.

O mecanismo do zkSync para transmissão de mensagens L1->L2 e Force Inclusion é manipulado através da função requestL2Transaction do contrato MailBox. Os usuários especificam o endereço L2, os dados de chamada, a quantidade de ETH a serem anexados, o valor L2GasLimit e outros detalhes. A função requestL2Transaction combina esses parâmetros em uma transação L2 e a coloca na PriorityQueue. Quando o Sequencer empacota transações e as carrega em L1 (por meio da função commitBatches), ele indica quantas transações devem ser retiradas do PriorityQueue para incluir nos registros de transação L2. Em termos de Inclusão de Força, o zkSync é semelhante ao Otimismo, onde o endereço L2 do iniciador (o mesmo que o endereço L1) é usado para chamar as funções relevantes e preencher os detalhes necessários (chamado, calldata, etc.), em vez de como o Arbitrum, que requer uma transação L2 assinada. No entanto, no design, ele é semelhante ao Arbitrum, pois ambos mantêm uma fila em L1, e o Sequencer pega transações pendentes enviadas diretamente pelos usuários da Fila e as grava no histórico de transações.

Se você depósito ETH através do ponte oficial do zkSync, como esta transação, ele chama a função requestL2Transaction do contrato MailBox. Essa função coloca a transação Deposit ETH L2 no PriorityQueue e emite um evento NewPriorityRequest. Como o contrato codifica os dados de transação L2 em uma cadeia de bytes, ele não é facilmente legível. No entanto, se você olhar para os parâmetros dessa transação L1, verá que o destinatário L2 também é o iniciador da transação (já que é um depósito para si mesmo). Depois de algum tempo, quando o Sequencer retirar essa transação L2 da PriorityQueue e incluí-la no histórico de transações, ela será convertida em uma transação L2 onde você será transferido para si mesmo. O valor da transferência será o valor ETH anexado pelo iniciador na transação de ETH de depósito L1. Na transação de Depósito L1, tanto o iniciador quanto o destinatário são 0xeDc1... 6909, o valor é de 0,03 ETH, e não há calldata. Na L2, haverá uma transação onde 0xeDc1... 6909 transferências para si mesmo. O tipo de transação (TxnType) é 255, indicando uma transação do sistema. Então, assim como experimentei a função de transação forçada no Optimism antes, chamei a função requestL2Transaction do zkSync e iniciei uma transação de autotransferência: nenhuma ETH foi anexada, e os dados de chamada continham a codificação HEX da cadeia de caracteres "force inclusion". Isso foi então convertido em uma transação L2 onde eu transfiro para mim mesmo, com os dados de chamada contendo a cadeia hexadecimal para "forçar inclusão": 0x666f72636520696e636c7573696f6e. Quando o Sequencer pega transações do PriorityQueue e as grava no histórico de transações, elas são convertidas em transações L2 correspondentes. Usando a função requestL2Transaction, os usuários podem enviar dados em L1 com a mesma conta L1 que seu endereço L2, especificando o destinatário L2, a quantidade de ETH a ser anexada e os dados de chamada. Se os usuários quiserem chamar outros contratos ou incluir dados diferentes, eles simplesmente precisam preencher os parâmetros na função requestL2Transaction. Ainda não há função de inclusão de força para usuários Embora uma transação L2 colocada no PriorityQueue tenha um período de espera calculado para inclusão pelo Sequencer, o design atual do zkSync não tem uma função Force Inclusion que permita aos usuários impô-la. Isso significa que é apenas uma solução parcial. Mesmo que haja um "período de espera para inclusão", em última análise, depende se o Sequencer decide incluí-lo: o Sequencer pode incluí-lo após o período expirar ou nunca incluir quaisquer transações do PriorityQueue. No futuro, o zkSync deve adicionar funções que permitam aos usuários incluir transações à força no histórico de transações L2 se elas não tiverem sido incluídas pelo Sequencer após o período de espera. Este seria um mecanismo de Inclusão de Força realmente eficaz. Resumir

L1 depende de um grande número de validadores para garantir a "segurança" e a "resistência à censura" da rede. Os rollups, no entanto, têm resistência à censura mais fracos porque as transações são gravadas por alguns ou até mesmo por um único Sequencer. Portanto, os Rollups precisam de um mecanismo de Inclusão de Força para permitir que os usuários ignorem o Sequencer e gravem transações no histórico, evitando que a censura do Sequencer torne o Rollup inutilizável e impedindo que os usuários retirem fundos. O Force Inclusion permite que os usuários gravem transações à força no histórico, mas o design deve escolher se "as transações podem ser imediatamente inseridas no histórico e entrar em vigor imediatamente". Se o efeito imediato for permitido, isso afetaria negativamente o Sequenciador, pois as transações pendentes em L2 poderiam ser afetadas por transações incluídas à força de L1. Portanto, os mecanismos atuais de Inclusão de Força em Rollups primeiro colocam as transações inseridas de L1 em um estado de espera e dão ao Sequencer uma janela de tempo para reagir e decidir se deseja incluir essas transações pendentes. O zkSync e o Arbitrum mantêm uma fila em L1 para gerenciar transações L2 ou mensagens enviadas de L1 para L2. A Arbitrum chama-lhe DelayedInbox; zkSync chama-lhe PriorityQueue. No entanto, o método do zkSync de enviar transações L2 é mais semelhante ao Optimism, onde as mensagens são enviadas de L1 usando o endereço L2, de modo que, quando convertido em uma transação L2, o iniciador é o endereço L2. A função para enviar transações L2 no Optimism é chamada de depositTransaction; no zkSync, ele é chamado requestL2Transaction. Em contraste, o Arbitrum gera uma transação L2 completa e a assina, em seguida, envia-a através da função sendL2Message. Em L2, o Arbitrum usa a assinatura para restaurar o signatário como o iniciador da transação L2. Atualmente, a StarkNet não possui um mecanismo de Inclusão de Força; O zkSync tem um mecanismo de Inclusão de Força implementado pela metade — ele tem um PriorityQueue e cada transação L2 na Fila tem um período de validade de inclusão, mas esse período de validade atualmente é apenas para exibição. Na prática, o Sequencer pode optar por não incluir nenhuma transação L2 do PriorityQueue.

Isenção de responsabilidade:

1. Este artigo é encaminhado de: [Geek Web3], o título original é "Theory and Practice: How to trigger censorship-resistant transactions in Ethereum Rollup?", atribuição de direitos autorais ao autor original [NIC Lin, Head of Taipei Ethereum Meetup], se você tiver alguma objeção à reimpressão, entre em contato Gate Learn Team, a equipe lidará com isso o mais rápido possível de acordo com os procedimentos relevantes.

2. Disclaimer: Os pontos de vista e opiniões expressos neste artigo representam apenas os pontos de vista pessoais do autor e não constituem qualquer conselho de investimento.

3. Outras versões linguísticas do artigo são traduzidas pela equipa do Gate Learn. Sem referenciar Gate.io, é proibido copiar, distribuir ou plagiar os artigos traduzidos.