Introdução ao mecanismo de inclusão de força do Rollup

Autor original: NIC Lin
Fonte original: médio
Que a força esteja com você. Este artigo apresentará o mecanismo anticensura de transações do Rollup - Forçar Inclusão, e usará o design e a prática de vários Rollups famosos como exemplos.
Foto de Artur Tumasjan no Unsplash
Conhecimento pré-requisito:
Saiba como funciona o Rollup e por que o Rollup precisa fazer upload de transações para L1
Resistência à censura de transações
A capacidade das transações serem resistentes à censura (resistentes à censura) é muito importante para um blockchain. Se um blockchain pode fazer transações para qualquer usuário censurado, então esse blockchain não é diferente de um servidor Web2. A atual resistência das transações do Ethereum à censura vem do grande número de validadores. Se Alice quiser revisar as transações de Bob e evitar que suas transações sejam carregadas na cadeia, então Alice terá que tentar subornar todos os validadores da rede, ou ela será. lixo. Toda a rede de e-mail continua enviando transações de spam superiores às transações de Bob para preencher os blocos. De qualquer forma, os custos dela serão muito altos.
Nota: Na atual arquitetura PBS do Ethereum, o custo da revisão foi de fato reduzido significativamente. Você pode consultar a revisão da OFAC sobre a proporção de blocos nas transações do Tornado Cash. A atual resistência à censura depende de verificadores e retransmissores independentes fora da OFAC e da jurisdição governamental.
Mas e os Rollups? O Rollup não requer um grande número de validadores para garantir sua segurança. Além disso, o Rollup possui apenas uma função centralizada (Sequenciador, chamado de sequenciador ou sequenciador) para blocos em lote e é tão seguro quanto L1. Mas segurança e resistência à censura são duas coisas diferentes. Construir um Rollup é tão seguro quanto o Ethereum, mas só possui um sequenciador centralizado. Então, o sequenciador pode revisar as transações de qualquer usuário, se desejar.
O sequenciador pode se recusar a receber transações do usuário, fazendo com que os usuários não consigam usar ou sair do Rollup.
mecanismo de inclusão forçada
Ao mesmo tempo, o Rollup deve ter tantos validadores quanto L1 para garantir a resistência à censura. É melhor usar diretamente a resistência à censura do L1: o sequenciador também compacta os dados da transação no contrato Rollup do L1. uma função no contrato Rollup para monitorar usuários. Você também pode inserir transações na classificação. Esse método é chamado de inclusão forçada. Enquanto o Sequencer não puder revisar as "transações L1" dos usuários monitorados, ele não poderá impedir que os usuários insiram à força transações Rollup através de L1, e a operação e a segurança do Rollup são baseadas nos recursos anticensura do L1.
O sequenciador não pode revisar as transações L1 do usuário, a menos que haja um custo muito complexo
Nota: A inclusão forçada só é possível se o Rollup for projetado. Os usuários podem definitivamente romper o L1 e inserir à força as transações do Rollup. Se o Rollup não fornecer um mecanismo de inclusão forçada, os usuários só poderão rezar para que a revisão do Sequencer não seja negociada por conta própria.
A transação entra em vigor imediatamente versus efeito retardado
Se permitirmos que as transações inseridas por meio da Inclusão Forçada sejam gravadas diretamente no histórico de transações do Rollup (com efeito imediato), o status do Rollup será alterado imediatamente. Por exemplo, Bob insere uma caneta por meio do mecanismo de Inclusão Forçada "Ele transferiu 1000 DAI. para a transação "Carol", se a transação entrar em vigor imediatamente, o saldo de Bob no estado mais recente será 1.000 DAI a menos e Carol terá 1.000 DAI a mais (é claro, a premissa é que o saldo de Bob exceda 1.000 DAI).
Se a transação de Bob puder ser gravada diretamente no histórico de transações e entrar em vigor imediatamente, o status do Rollup mudará imediatamente.
Se o sequenciador estiver coletando transações fora da cadeia neste momento e esperar até que a próxima transação seja enviada para o contrato Rollup, ele poderá ser afetado pela transação que Bob insere à força e entra em vigor imediatamente. Por exemplo, Bob só precisa enviar uma transação de pagamento de "ele" transfere 1000 DAI para Alice "para o Sequencer com antecedência. O Sequencer equivale a verificar se não há problema e prometer receber renda. Tanto Alice quanto Bob podem consultar o Sequencer se a transação será recebida e calculará o resultado mais recente (Alice tem 1000 DAI a mais e Bob tem 1000 DAI a menos). Mas quando o sequenciador descobriu que Bob havia se apressado para inserir a transação à força, o status de execução das transações em sua mão havia mudado. Ele sabia que a transação “Bob transferiu 1000 DAI para Alice” havia se tornado uma falha de execução e Alice não poderia. obtê-lo.
O sequenciador recebe a transação de Bob, então Alice acredita que receberá 1000 DAI
Como resultado, Bob forçou diretamente o recebimento de outra transação conflitante em L1, fazendo com que a transação nas mãos do Sequenciador não fosse recebida e Alice não conseguisse obter DAI.
Esta pode não ser uma boa experiência para o usuário, portanto o Rollup geralmente faz com que a transação de inclusão forçada entre em vigor imediatamente, mas avança a transação para um estado de "preparação". O Sequenciador pode escolher se deseja adicionar as transações que entram no estado de "preparação" ao final do lote quando a transação de orçamento for enviada. Se o Sequenciador nunca quiser processar esses estados de "preparação", essas transações serão processadas após um. período de tempo. Após um certo período de tempo, ele pode ser inserido à força no histórico de transações.
Bob quer enganar Alice forçando a transação de receita, mas na verdade a transação será colocada na fila primeiro
O Sequenciador pode decidir por si mesmo quando "incluir" as transações em espera na fila, de modo que a transação de Bob para Alice DAI será executada primeiro.
Se o Sequenciador não estiver aguardando transações na fila, após um determinado período de tempo o próprio usuário (ou qualquer pessoa) poderá forçar a receita.
O sequenciador se recusa a receber a transação de Bob, então Bob coloca a transação na fila de L1
O sequenciador ainda pode continuar rejeitando transações na fila por algum tempo
No entanto, o Sequencer não pode rejeitar transações que esperam na fila para sempre. Após um período de tempo, qualquer pessoa pode acionar a renda forçada. A seguir, apresentaremos a implementação do mecanismo de contenção de força do Rollup mais famoso, como Optimism, Arbitrum, StarkNet e zkSync. .
Mecanismo inclusivo de poder otimista
Primeiro, vamos apresentar o processo de depósito do otimismo. Este depósito não se refere apenas ao depósito de dinheiro no otimismo, mas é equivalente ao “depósito de mensagens para L2” mais geral. Após receber a mensagem recém-depositada, o nó L2 transmite a mensagem e a converte em uma transação da porta L2 para execução e transmite a mensagem ao destinatário designado.
Mensagem de usuário depositando dinheiro de L1 para L2
Contrato L1CrossDomainMessenger
Quando um usuário decide depositar tokens ETH ou ERC-20 no Optimism, ele interage (cross-web) com o contrato L1StandardBridge em L1, especificando quanto depositar e de qual endereço recebê-lo, etc. Em seguida, a mensagem de conexão L1StandardBridge é passada para o contrato L1CrossDomainMessenger da próxima camada. Este contrato é usado principalmente como um contrato de comunicação geral entre L1 e L2. L1StandardBridge usa este contrato de comunicação geral para se comunicar com L2StandardBridge em L2 para decidir quem pode começar por cunhar. tokens de L2 ou retirada de tokens de L1. Se um desenvolvedor precisar desenvolver um contrato para interoperabilidade e status de sincronização entre L1 e L2, ele poderá construí-lo em L1CrossDomainMessenger.
O contrato CrossChainMessenger de mensagens do usuário é passado de L1 para L2
Contrato do Portal Otimismo
O contrato L1CrossDomainMessenger enviará a mensagem para o contrato OptimismPortal de nível mais baixo. Após o processamento do contrato OptimismPortal, ele emitirá um evento TransactionDeposited. Os parâmetros do evento incluem "a pessoa que enviou a mensagem", "a pessoa que recebeu a mensagem. "e parâmetros de execução relacionados.
Em seguida, o nó Optimism de L2 ouvirá o evento TransactionDeposited emitido pelo contrato OptimismPortal e converterá os parâmetros do evento em uma transação que registra L2. O iniciador desta transação L2 pode ser o "remetente da mensagem" no evento TransactionDeposited, a pessoa que enviou a transação O destinatário será a “pessoa que receberá a mensagem” no evento, e outros parâmetros de execução também serão passados ​​pelos parâmetros do evento.
O nó L2 insere o evento TransactionDeposited emitido pelo OptimismPortal em transações L2 anotadas
Por exemplo, esta é uma transação em que um usuário deposita 0,01 ETH através do contrato L1StandardBridge. Esta mensagem e o ETH são transmitidos até o contrato OptimismPortal (o endereço é 0xbEb5...06Ed). em uma transação L2 e o iniciador da mensagem é o contrato L1CrossDomainMessenger. O destinatário é o contrato L2CrossDomainMessenger que vem com 0,01 ETH;
inclusão forçada
Quando o usuário deseja forçar a execução de sua transação de forma otimista, ele não precisa enviar uma mensagem de L1 para L2, portanto não utilizará o contrato L1CrossDomainMessenger. O efeito que ele deseja alcançar é fazer com que a fatura específica "a transação que ele envia e executa em L2 a partir de seu endereço L2" seja executada sem problemas, para que ele interaja diretamente com o contrato OptimismPortal e deixe seu endereço L2 chamar o contrato OptimismPortal, então que quando o evento TransactionDeposited for convertido em uma transação L2, o "iniciador da transação" será seu endereço L2", para que a transação possa ser vista novamente.
Na transação L2 convertida do evento TransactionDeposited, o iniciador será o próprio Bob; o destinatário será o contrato Uniswap e será acompanhado pelo ETH especificado, assim como o próprio Bob iniciou a transação L2;
Use o endereço L2 para chamar a função depositTransaction assinada pelo OptimismPortal, e lembre-se de preencher os parâmetros da transação L2 um por um.
Fiz uma transação simples de inclusão forçada: transferi dinheiro para mim mesmo no meu endereço L2 (0xeDc1...6909) e anexei uma mensagem de texto de "inclusão forçada". Esta é a transação L1 onde executei a função depositTransaction por meio do contrato OptimismPortal. Você pode ver que no evento TransactionDeposited emitido, from e to são eu mesmo e o valor no campo opaqueData restante (0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000). 00000000000000000000000000000000000000000000015BE00000000000C35000666F72636520696E636C7573696F6E) Quanto está codificado? “Quanto ETH a pessoa traz”, “O iniciador da transação L2 deve trazer ETH para o destinatário L2”, “Limite de gás da transação L2” e “Dados para o destinatário L2” e outras informações.
Evento TransactionDeposited emitido pela transação L1
Após interpretar os valores numéricos de diversas informações neste opaqueData, você obterá:
"Quanto ETH está vinculado à pessoa que ligou para DepositTransaction": 0 porque não quero recarregar ETH de L1 para L2
"Quanto ETH o iniciador da transação L2 precisa enviar ao destinatário L2": 5566 (wei), porque quero transferir dinheiro para mim mesmo
"Limite de Gás de Transação L2": 50.000
"Dados para receptor L2": 0x666f72636520696e636c7573696f6e, limpe a "inclusão forçada" da codificação hexadecimal desta string
Pouco tempo depois, apareceu a transação L2 convertida: registre a transação L2 que transferi dinheiro para mim mesmo, o valor é 5566 e os dados são a string de "inclusão obrigatória". E você pode notar que o Tipo Txn (tipo de transação) em Outros Atributos na penúltima linha da figura é a transação do sistema 126 (Sistema), o que significa que a transação não foi iniciada por mim em L2, mas foi convertida de o evento L1TransactionDeposited.
Conversão concluída transação L2
Caso o usuário queira chamar outros contratos com dados diferentes, o mesmo é feito preenchendo os parâmetros na carta depositTransaction um por um. Basta lembrar de utilizar o endereço L2 para executar em L1, para que seja o iniciador da transação L2. será o endereço L2.
janela do sequenciador
O nó Optimism L2 mencionado anteriormente converte o evento TransactionDeposited em uma transação L2. Na verdade, este nó Optimism refere-se ao nó Sequencer. Afinal, trata-se de sequenciamento de transação, portanto, apenas o Sequencer pode decidir quando convertê-lo em uma transação L2. . Ao ouvir o evento TransactionDeposited, o sequenciador pode não necessariamente converter o evento em uma transação L2 imediatamente, mas pode decidir convertê-lo por um período de tempo. Esse período de tempo é chamado de janela do sequenciador no Optimism. mainnet é atualmente de 24 horas. Então, quando o usuário começar a depositar dinheiro de L1 ou receber um lembrete, ou incluir à força uma transação de recarga, o pior cenário será que ele seja oficialmente incluído no histórico de transações L2 24 horas depois, mas pelo menos isso é melhor do que a transação que nunca pode ser evitada. O resultado de ser incluído.
Mecanismo de inclusão forçada da Arbitrum
No otimismo, a operação de depósito de L1 emitirá um evento TransactionDeposited, e o resto é esperar que o Sequenciador receba a operação de depósito, mas em qualquer operação de L1 (depositar dinheiro ou enviar mensagens para L2, etc.) será armazenado; em uma fila acordada por L1 , ao invés de apenas emitir eventos. O sequenciador terá um período de tempo para adicionar as operações L1 nesta fila ao histórico de transações. Se o sequenciador se esgotar quando o tempo acabar, ele poderá ser concluído sem que ninguém precise substituí-lo.
A arbitragem manterá uma fila no contrato L1. Se o Sequenciador não receber ativamente as transações na fila, quando o tempo acabar, qualquer pessoa poderá forçar as transações na fila a serem inseridas no histórico de transações.
Todas as operações L1 são contratos de caixa de entrada atrasada, como o nome indica, as operações aqui serão atrasadas e expirarão; o outro contrato é o Sequencer Inbox, que é uma interface para upload de transações L2 para o Sequencer. As transações carregadas pelo Sequencer serão gravadas diretamente no histórico de transações. Além disso, quando o Sequencer for carregado, você pode escolher quantas operações L1 retirar da Caixa de Entrada Atrasada e gravá-las juntas no histórico de transações, para que essas operações L1 possam ocorrer. efeito.
SequencerInbox contém histórico de transações. Geralmente, apenas Sequencer pode gravar diretamente novas transações;
Quando o Sequencer grava uma nova transação, ele pode iniciar uma transação do DelayedInbox e escrevê-la junto.
Projetos complexos e documentação impressionante
Se os leitores consultarem diretamente o capítulo oficial do Arbitrum sobre Sequenciador e Inclusão de Força, eles verão como a Inclusão de Força mencionada lá é compatível, bem como alguns nomes de parâmetros e nomes de funções: O usuário primeiro vai para a Caixa de entrada para marcar um horário para chamar a função sendUnsignedTransaction Se o Sequencer não estiver no compromisso Income dentro de 24 horas, o usuário poderá chamar a função forceInclusion assinada pelo Sequencer Inbox. Desta forma, mesmo o link não está anexado, e você só pode concordar com a função correspondente no código do programa.
Ao encontrar a função sendUnsignedTransaction, você descobrirá que realmente precisa preencher você mesmo o valor nonce e o valor maxFeePerGas. Qual endereço é o nonce? Qual rede é o valor maxFeePerGas? Qual a melhor forma de preencher? Não há documentação, nem mesmo da Natpsec. Aí você também encontra uma função que acumula skins: sendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction. Também não há nenhum documento informando a diferença entre essas funções, como usá-las e como preencher os parâmetros, nem mesmo Natpsec.
Você considera tudo e tenta antes de preencher os parâmetros e enviar a transação. Você deseja usar tentativa e erro para ver se consegue encontrar o método correto, mas descobre que todas essas funções usarão seu endereço L1 como um. alias de endereço, resultando no final O iniciador da transação em L2 é basicamente um endereço diferente, portanto, seu endereço L2 não se move.
Enviar mensagem L2
Mais tarde, cliquei acidentalmente em um link na página de pesquisa do Google e descobri que o Arbitrum originalmente tinha uma biblioteca de tutoriais. Ela continha um script demonstrando como enviar transações L2 de L1 (ou o que significa Forçar Inclusão) e sua função era completa. diferente do mencionado acima. Qualquer uma delas é apenas uma função chamada sendL2Message, e o parâmetro message é na verdade uma transação Arbitrum L2 assinada? ? ? Quem saberia que “enviar mensagens L2” significaria na verdade “transação L2 assinada”? ? E mais uma vez, não há documentação ou Natspec explicando quando e como usar esta função.
Conclusão: É problemático gerar manualmente uma transação de renda forçada do Arbitrum. Recomenda-se seguir o tutorial oficial e executar o SDK do Arbitrum. Ao contrário de outros Rollups, o Arbitrum possui documentação clara do desenvolvedor e notas de código do projeto. A finalidade e os parâmetros de muitas funções carecem de explicação, fazendo com que os desenvolvedores gastem mais tempo do que o esperado para acessá-lo e usá-lo. Também perguntei às pessoas da Arbitrum sobre o Arbitrum Discord, mas não obtive uma resposta satisfatória.
Nota: Quando perguntei no Discord, a outra parte apenas me pediu para ouvir sendL2Message. Não houve necessidade de explicar para que servem outras funções (mesmo sendUnsignedTransaction mencionadas no arquivo de inclusão obrigatória), como usá-las e quando. usa-os.
Infelizmente, a StarkNet atualmente não impõe inclusão. Existem apenas dois artigos no fórum oficial que discutem censura e mecanismos de inclusão obrigatória.
Incapaz de provar falha na transação
A razão é que o sistema de prova de conhecimento zero da StarkNet não pode provar transações que não foram registradas, portanto, o crédito forçado não pode ser permitido. Porque se alguém maliciosamente (ou não intencionalmente) forçar a entrada de uma transação que falha e não pode ser provada, a StarkNet ficará diretamente presa: porque depois que a transação é inserida à força, o Prover deve provar a transação falhada, mas não tem como provar isso .
A StarkNet espera introduzir a função de comprovar transações com falha na versão v0.15.0, e então deverá ser possível implementar ainda mais o mecanismo de inclusão obrigatória.
Mecanismo de inclusão obrigatória do zkSync
A passagem de mensagem L1-> L2 do zkSync e o mecanismo de inclusão forçada são todos executados por meio da função requestL2Transaction do contrato MailBox. O usuário especifica o endereço L2 a ser chamado, os dados da chamada, a quantidade de ETH no cinto, o valor do limite de gás L2. , etc., e divide os parâmetros de requestL2Transaction Combine-o em uma transação L2 e então simule a fila de prioridade (Fila de prioridade) especificará quantas transações serão retiradas da fila de prioridade quando o backup da transação for carregado para L1. (função commitBatches).
zkSync é muito semelhante ao Optimistic em termos de interface de inclusão forçada. Ambos usam o endereço L2 do usuário para ligar e preencher dados relevantes (chamado, dados de chamada, etc.), em vez de preencher uma transação L2 assinada como Arbitrum ; em termos de design, as transações são iguais ao Arbitrum na manutenção de uma fila de entidades em L1, e o Sequenciador pega as transações da fila e as grava no histórico de transações.
O usuário insere transações L2 na fila de prioridade por meio de requestL2Transaction, e o sequenciador pode se comunicar com a transação da fila de prioridade ao confirmar Batches.
Se você recarregar ETH através da ponte oficial do zkSync, que equivale à transação neste momento, ele chamará a função requestL2Transaction do contrato MailBox. Ele manterá o ETH recarregado na fila de prioridade de transação L2 e emitirá um evento NewPriorityRequest. Como o contrato codifica os dados da transação L2 em uma sequência de bytes, não é fácil de ler. Se você observar os parâmetros da transação L1, verá que o destinatário de L2 nos parâmetros também é o iniciador do. transação porque (é Depósito para você mesmo), então Depois de um tempo, quando a transação L2 de troca for retirada da fila de prioridade pelo sequenciador e incluída no histórico de transações, ela será convertida em L2 em uma transação que registra a transferência para si mesmo, e o valor da transferência é o do iniciador da transação em L1. O valor de ETH trazido para o depósito na troca de ETH.
Na transação de recarga L1, o iniciador e o receptor da transação são 0xeDc1…6909, o valor é 0,03 ETH e os dados da chamada estão vazios.
A contabilidade 0xeDc1…6909 aparecerá em L2, uma transação que você transfere para si mesmo. O tipo de transação (Tipo Txn) é 255, que é uma transação do sistema.
Em seguida, chamei a carta requestL2Transaction diretamente de acordo com o script e enviei para mim mesmo a transação que gravou a chamada: sem nenhum ETH, os dados da chamada incluíam a codificação hexadecimal da string de "inclusão forçada". A fórmula subsequente é convertida em uma transação em L2 que registra sua própria chamada. Os dados da chamada contêm a string de "inclusão forçada": 0x666f72636520696e636c7573696f6e.
Quando o sequenciador retira a transação da fila de prioridade e a grava no histórico de transações, ela pode ser convertida na transação L2 correspondente em L2
Através da função requestL2Transaction, os usuários podem solicitar uma transação L2 em L1 com o endereço L2, especificando o destinatário L2, a quantidade de ETH trazida e os dados da chamada. Caso o usuário queira chamar outros contratos com dados diferentes, ele também precisará preencher os parâmetros um por um na função requestL2Transaction. Basta lembrar de usar o endereço L2 para executar em L1, para que o iniciador da transação L2 seja o L2. endereço. .
Não há função que permita aos usuários forçar a renda
Embora colocar as transações L2 na fila de prioridade calcule automaticamente o período para as transações L2 serem coletadas pelo sequenciador, o design atual do zkSync não inclui funções relacionadas obrigatórias que os próprios usuários podem executar, o que equivale a meio conjunto. Portanto, embora exista um "período de validade da receita", na verdade ele ainda depende se o Sequenciador deseja receber receita: o Sequenciador pode esperar até a transição para receber a receita ou nunca poderá receber nenhuma transação na fila de prioridade. No futuro, o zkSync deverá adicionar funções relevantes para que os usuários possam forçar a renda quando a renda tiver passado, mas ainda não tiver sido recebida pelo Sequenciador. Este é um mecanismo de inclusão forçada verdadeiramente eficaz.
Resumir
L1 depende de um grande grupo de pessoas para garantir a "segurança" e "resistência à censura" da Internet, enquanto Rollup depende da "resistência à censura de L1" para obter "a mesma segurança que L1", mas não inclui a resistência à censura de Rollup. habilidade
Pelo contrário, como o Rollup usa um pequeno número ou mesmo um único sequenciador para escrever transações, sua capacidade anticensura é ainda mais fraca. Portanto, o Rollup precisa de um mecanismo de Força de Inclusão para permitir que os usuários ignorem o Sequencer e gravem transações no histórico para evitar serem revisados ​​pelo Sequencer e incapazes de usar ou sair do Rollup.
A inclusão forçada permite que os usuários forcem a gravação de transações no histórico, mas no design, eles precisam escolher se a transação pode ser inserida imediatamente no histórico e entrar em vigor imediatamente. Se as transações tiverem efeito imediato, isso causará problemas para o sequenciador e dificuldade na experiência do usuário, porque as transações que aguardam para serem recebidas em L2 podem ser afetadas por transações recebidas à força em L1.
Portanto, o atual mecanismo de inclusão forçada de Rollup primeiro colocará as transações inseridas em L1 em ​​um estado de espera e dará ao Sequenciador um período de tempo para reagir e escolher se deseja incluir essas transações em espera.
Tanto o zkSync quanto o Arbitrum mantêm uma fila de entidades em L1 para gerenciar transações L2 enviadas por usuários de L1 ou mensagens para L2. Arbitrum chama isso de caixa de entrada adiada; zkSync chama isso de fila prioritária;
No entanto, a forma como o zkSync envia transações L2 é semelhante ao Optimism. Elas são enviadas para L1 usando o endereço L2, portanto, o iniciador da transação L2 será o endereço L2. A função do Optimism para enviar transações L2 é chamada depositTransaction; zkSync é chamada requestL2Transaction. O Arbitrum cria uma transação L2 concluída e a assina e, em seguida, a envia por meio da carta sendL2Message. O Arbitrum restaurará o signatário por meio da assinatura em L2 como o iniciador da transação L2.
Atualmente, a StarkNet não possui um mecanismo de inclusão forçada. O zkSync implementou meio conjunto de inclusões obrigatórias - há uma fila de prioridade e as transações L2 em cada fila têm um período de validade de renda, mas atualmente esse período de validade é apenas para decoração, na verdade. , o sequenciador pode escolher Não receber mais nenhuma transação L2 na fila de prioridade