Ainda ontem, ocorreu um acontecimento chocante: a Linea, a solução Ethereum Camada 2 desenvolvida pela Consensys, a empresa-mãe da Metamask, foi proactivamente encerrada. 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 de 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 acima mencionados reside na imperfeição da infraestrutura, especificamente a sua falta de descentralização. Se um blockchain fosse suficientemente descentralizado, ele não deveria ser capaz de desligar tão facilmente. Devido à estrutura única do Ethereum Camada 2, a maioria das soluções Camada 2 dependem de 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 Camada 2 sequenciadores dificilmente alcançarão 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 abordagens diferentes para resolver esta questão. Por exemplo, Loopring, Degate e StarkEx introduziram funções de retirada forçada e escape hatch, enquanto Arbitrum e outros Optimistic Rollups 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.

Transaction Censorship and Force Inclusion

Censorship resistência em transações é crucial para qualquer blockchain. Se um blockchain pode censurar arbitrariamente e rejeitar transações do usuário, não é diferente de um servidor Web2. O resistência à censura de transações da Ethereum é atualmente assegurado pelos seus inúmeros 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 de Bob, ocupando assim espaço em blocos. Ambos os métodos são extremamente dispendiosos.

Nota: Na atual arquitetura PBS (Proposer-Builder Separação) do Ethereum, o custo de censurar transações é significativamente reduzido. Por exemplo, você pode olhar para a proporção de blocos que cumprem com a censura do OFAC às transações do Tornado Cash. O 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 rollups não requerem 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, a segurança e a resistência à censura são duas questões diferentes. Um Rollup, embora seja tão seguro quanto Ethereum, ainda pode censurar a transação de qualquer 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 próprio contrato de Rollup. Esse mecanismo é conhecido como "Inclusão de Força". Por longo que 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. Desta 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 for permitido que as transações sejam gravadas diretamente no contrato do Rollup por meio do Force Inclusion (o que significa que elas entrarão em vigor imediatamente), o estado do Rollup mudará instantaneamente. Por exemplo, se Bob usa o mecanismo de Inclusão de Força para inserir uma transação que transfere 1000 DAI para Carol, e a transação entra 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 de Força permitir que as transações sejam gravadas diretamente no contrato de Rollup e entrem em vigor imediatamente, o estado do Rollup mudará instantaneamente. Se o sequenciador estiver simultaneamente coletando fora da cadeia transações e se preparando para enviar o próximo lote para o contrato de Rollup, ele pode ser interrompido pela transação inserida à força de Bob que entra em vigor imediatamente. Para evitar esse problema, os pacotes cumulativos geralmente não permitem que as transações Force Inclusion entrem em vigor imediatamente. Em vez disso, os usuários inicialmente inserem suas transações em uma fila de espera no L1, onde entram em um estado de "preparação". Quando o sequenciador empacota fora da cadeia transações 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", uma vez que o período da janela termina, os usuários podem 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 recusar consistentemente, após um determinado período, qualquer pessoa pode usar a função Force Inclusion 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 pode usar a função Force Inclusion 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.

Optimism's Force Inclusion mechanism

Primeiro, vamos discutir o processo de depósito do Otimismo. Este processo de depósito envolve não só a transferência de fundos para o Optimism, mas também o envio de "mensagens de utilizador 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 de frontend, especificando a quantidade a 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 cunhar 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 neste artigo, CrossDomainMessenger é escrito como CrossChainMessenger.

Contrato OptimismPortal

O contrato L1CrossDomainMessenger encaminha a mensagem para a camada mais baixa, o contrato OptimismPortal. Depois de processar a mensagem, o contrato OptimismPortal emite um evento chamado TransactionDeposited, que inclui parâmetros como o "remetente", o "destinatário" e outros detalhes de execução relevantes. 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 "emissor" especificado no evento, o recetor será o "recetor" mencionado no evento, e outros detalhes da transação também serão derivados dos parâmetros do evento.

Os 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... Alguns minutos depois, isso é convertido em uma transação L2: o remetente da mensagem é o contrato L1CrossDomainMessenger, o recetor é 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 0,01 ETH para o L2StandardBridge, que posteriormente o transfere para Bob.

Como acioná-lo

Se você quiser incluir à força uma transação no contrato Rollup da Optimism, seu objetivo é garantir que uma transação "iniciada e executada a partir do seu endereço L2 em L2" possa ser executada com sucesso. Para conseguir isso, você deve enviar a mensagem diretamente para o contrato OptimismPortal usando seu endereço L2 (observe que o contrato 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 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 recetor será o contrato Uniswap e incluirá o ETH especificado, como se Bob estivesse iniciando ele mesmo a transação L2.

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 em 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 o 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 emissor quanto o recetor sou eu mesmo.

Os valores restantes na coluna Dados opaca codificam informações como "quanto ETH a pessoa que chama a função depositTransaction anexada", "quanto ETH o iniciador da transação L2 deseja enviar ao recetor", "L2 transaction GasLimit" e "Data for the L2 receiver". Depois de decodificar essas informações, você obterá os seguintes detalhes: "quanto ETH a pessoa que está chamando a depositTransaction anexada": 0, porque eu não estou depositando ETH de L1 para L2; "quanto ETH o iniciador da transação L2 deseja enviar ao destinatário": 5566 (wei); "Transação L2 GasLimit": 50000; "Dados para o recetor L2": 0x666f72636520696e636c7573696f6e, que é a codificação hexadecimal da string "force inclusion". Pouco depois, a transação L2 convertida apareceu: uma transação L2 onde eu transfiro 5566 wei 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 Depositado 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 o seu conta L2 ao chamar a função depositTransaction. Desta forma, quando o Evento Depositado for convertido numa transação L2, o iniciador será o seu L2 conta. Janela do Sequencer O nó Optimism L2 que converte o evento Transaction Deposited em uma transação L2 é, na verdade, o Sequencer. Como isso envolve ordem de transação, somente o Sequencer pode decidir quando converter o evento em uma transação L2. Quando o Sequencer ouve 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 rede principal do Optimism é de 24 horas. Isso significa que quando um usuário deposita dinheiro de L1 ou usa a Inclusão de Força 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

No Otimismo, a operação L1 depósito dispara um evento Transaction Deposited, e então é apenas uma questão de esperar que o Sequencer 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 fazê-lo dentro deste período de tempo, qualquer pessoa pode 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 pode 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 adiadas 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.

Design 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 tem que 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 é nonce? Qual rede é maxFeePerGas? Como deve ser preenchido corretamente? Não há documentos de referência, nem mesmo NatSpec. Você também encontrará muitas funções semelhantes no contrato Arbitrum: 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 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 em 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 Force Inclusion). 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 à 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 sendL2Message e não explicaram as funções de outros métodos (incluindo aqueles mencionados na documentação Force Inclusion como sendUnsignedTransaction), seus propósitos, 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 da Força. A razão para a incapacidade de provar transações falhadas é que o sistema de prova de conhecimento zero da StarkNet não pode provar uma transação falhada, portanto, a Inclusão de Força não pode ser permitida. Se alguém maliciosamente (ou sem intenção) forçar inclui uma transação falhada e não provável, StarkNet ficaria preso: 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 falhadas na versão v0.15.0, após o que o mecanismo de Inclusão de Força deve ser implementado.

, o mecanismo do zkSync para transmissão de mensagens L1->L2 e Force Inclusion é tratado 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 anexar, 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 para L1 (por meio da função commitBatches), ele indica quantas transações devem ser feitas do PriorityQueue para incluir nos registros de transações L2. Em termos de Force Inclusion, o zkSync é semelhante ao Optimism, 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 (callee, calldata, etc.), em vez de como o Arbitrum, que requer uma transação L2 assinada. No entanto, no design, é 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. Esta 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, não é facilmente legível. No entanto, se você olhar para os parâmetros desta transação L1, verá que o destinatário L2 também é o iniciador da transação (uma vez 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ê transfere 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 como o destinatário estão 0xeDc1... 6909, o valor é de 0,03 ETH, e não há dados de chamada. No L2, haverá uma transação onde 0xeDc1... 6909 transfere-se para si próprio. 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 calldata continham a codificação HEX da string "force inclusion". Isso foi então convertido em uma transação L2 onde eu transfiro para mim mesmo, com os calldata contendo a string hexadecimal para "inclusão de força": 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 o mesmo conta L1 que seu endereço L2, especificando o destinatário L2, a quantidade de ETH a anexar 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. Nenhuma função de inclusão de força para usuários ainda 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. Isto 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 nenhuma transação 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ças verdadeiramente 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 escritas 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, impedindo que a censura pelo Sequencer torne o Sequencer inutilizável e impeça os usuários de retirar fundos. 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 inseridas imediatamente no histórico e entrar em vigor imediatamente". Se o efeito imediato for permitido, isso afetará negativamente o Sequencer porque as transações pendentes em L2 podem 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 depositTransaction; em zkSync, é chamado requestL2Transaction. Em contraste, Arbitrum gera uma transação L2 completa e assina-a, 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ças; 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.

Declaração de exoneração de responsabilidade:

1. Este artigo é encaminhado de: [Geek Web3], o título original é "Teoria e Prática: Como desencadear transações resistentes à censura no Ethereum Rollup?", atribuição de direitos autorais ao autor original [NIC Lin, Chefe do Taipei Ethereum Meetup], se você tiver alguma objeção à reimpressão, entre em contato Gate Learn Team, a equipe irá lidar com isso o mais rápido possível de acordo com os procedimentos relevantes.

2. Declaração de exoneração de responsabilidade: 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 fazer referência a Gate.io, é proibido copiar, distribuir ou plagiar os artigos traduzidos.