** Jinjin Finance Blockchain, 10 de junho ** Um bug no código classificador da Arbitrum esta semana causou uma breve interrupção da capacidade da rede de enviar transações em lotes, e as transações não puderam ser confirmadas na cadeia principal. A vulnerabilidade foi corrigida e a função de envio de lote de transações foi restaurada. Em 10 de junho, a Fundação Arbitrum divulgou o relatório de análise pós-fato sobre o bug do classificador Arbitrum. Em seguida, vamos revisar e ver por que esse evento de bug não causou a perda de fundos do usuário.
Linha do tempo do evento de erro do Classificador Arbitrum
Às 06h04min53s do dia 7 de junho de 2023, o emissor do lote não conseguiu atualizar sua exibição de estado L1 devido a um problema temporário com o nó L1 do classificador Arbitrum. Devido a um problema de causa raiz, o classificador Arbitrum continuou tentando consultar o estado de seu número de bloco de visualização L1 anterior. Isso significa que, mesmo depois que o problema temporário do nó L1 for resolvido, o publicador do lote continuará tentando consultar o estado do antigo número do bloco L1 e o nó L1 não terá mais seu estado porque não é um nó de arquivo.
Às 09h38min28s do dia 7 de junho de 2023, o anunciante do lote da Arbitrum parou de publicar transações porque atingiu o limite máximo configurado de transações na fila (256), que é o mesmo que o limite do mempool. Se esse limite não for atingido, a postagem em massa continuará normalmente.
Às 11h09 do dia 7 de junho de 2023, devido a lotes não publicados, foi acionado um alerta no contrato inteligente do Sequencer Inbox para verificar a existência de novos lotes e um aviso foi enviado ao canal Slack.
Às 11h10, a falta de lançamentos de lote recentes acionou um alerta baseado em log e enviou um alerta de nível crítico para o canal Slack.
Às 11h13, um membro da equipe da comunidade iniciou o PagerDuty com um membro da equipe SRE, que prontamente reconheceu o incidente e começou a responder.
Às 11:19:02 da manhã, a equipe do SRE reiniciou o batch poster, mas devido ao limite máximo de transações em fila mencionado anteriormente, o batch poster foi impedido de publicar transações. A equipe SRE notou esse problema e começou a mudar para um provedor L1 RPC terceirizado na tentativa de atenuar o problema.
Às 11h24min16s, 5 minutos após o início do pôster do lote, ele atualizou a visualização do estado L1 e publicou o primeiro lote de transações.
Às 11h25min09s, a configuração do pôster de lote foi alterada para usar um provedor L1 RPC terceirizado e reiniciada porque a equipe SRE já havia começado a fazer essa alteração e não notou o lote. Após uma reinicialização, as transações em lote continuam a ocorrer.
Às 11h30min21s da manhã, 5 minutos após o início do pôster do lote, a visualização do estado L1 foi atualizada, o que fez com que o estado L1 ficasse fora de sincronia, o que também era a causa raiz do problema. O estado L1 foi atualizado para o número do bloco final 17428199, mas usou o último nonce 178078, correspondente ao bloco mais recente no momento, em vez do bloco final armazenado em seu estado, resultando na limpeza de todas as transações enfileiradas no Redis Exceto, porque o Redis considera essas transações como confirmadas.
Às 11h30min26s, o anunciante do lote postou um novo lote. O Redis depende da exibição do estado L1 para determinar o que publicar, mas neste ponto a fila do Redis está vazia, conforme declarado anteriormente, o estado L1 está incorreto e um lote foi publicado com um número aleatório no estado 178078, mas para Determinar o lote a ser publicado, usando um número de bloco irrelevante 17428199, resultando na publicação de um lote antigo com um número de série 229209, que na verdade foi publicado às 11:24:16 antes e, em seguida, o pôster do lote reiniciou a inicialização. Como o lote antigo 229209 já foi publicado, a transação L1 enviada pelo lote foi revertida.
Às 11h36min35s, o endereço do anunciante do lote ficou sem Ether porque não reembolsou a taxa de gás, então parou de publicar. Este é um mecanismo intencional para evitar que o anunciante do lote consuma todo o gás armazenado no custo do lote de recuperação.
Às 11h46, um membro da equipe Nitro recebeu uma ligação para resolver um problema de software com a recuperação em lote.
Por volta das 11h58, a Arbitrum começou a receber relatórios de que alguns usuários descobriram que havia um problema com o classificador (transmitindo transações recém-classificadas para nós RPC), porque cada vez mais transações ordenadas eram devido a problemas de postagem em lote, em vez de postagem para a cadeia, esse problema afeta principalmente os clientes de feed com conexões de Internet ruins ou alocação de memória insuficiente, pois é mais provável que caiam e tenham problemas de reconexão. A Arbitrum recomenda que os usuários que executam vários nós RPC executem uma retransmissão de alimentação local para reduzir a largura de banda externa necessária.
Às 12h03, a Arbitrum removeu o limite de taxa de alimentação da Cloudflare para aliviar o problema de os clientes atingirem o limite de taxa ao tentar se reconectar após serem desconectados devido a uma conexão com a Internet.
Às 12h05, a Arbitrum removeu todos os limites de taxa do Cloudflare para permitir maior utilização de RPC público para aqueles cujos nós estavam tendo problemas para manter conexões com o feed.
Às 12h12min09s, o pôster de lote com defeito foi encerrado e o armazenamento de fila do Redis foi limpo para remover o estado incorreto.
Às 12h12min40s, o pôster do lote começou na versão antiga v2.0.14 e não houve problema de raiz.
Às 12h21min56s, o primeiro lote de pôsteres recém-abertos foi bem-sucedido, e eles estão sendo exibidos continuamente desde então.
Lições aprendidas sobre o evento de erro do classificador Arbitrum
Esta falha foi causada por um bug no poster do lote. O próprio sequenciador não foi afetado ou interrompido e continuou processando as transações durante todo o processo. Os relatórios de que o sequenciador ficou sem fundos estão incorretos. O mecanismo de financiamento da Arbitrum consiste em duas carteiras, a saber: a carteira "sequencer" e a carteira "gas-refunder". Somente quando o sequenciador conseguir liberar o lote com sucesso, ele será reembolsado. Falha, fundos e os problemas relacionados não foram causados pelo sequenciador ficando sem fundos, portanto, nenhum fundo do usuário estava em risco.
A Arbitrum limpará as opções de configuração que foram adicionadas na solução temporária. Posteriormente, planeja reavaliar os problemas de tempo limite do cliente e do servidor do sequenciador para melhorar a confiabilidade da rede no caso de atrasos nas transações. Uma nova "v2.1.0-beta .2" versão beta. Além disso, o Arbitrum criará uma página de status da rede pública para reduzir a confusão se houver problemas com o serviço.
Este artigo é referenciado no site oficial da Fundação Arbitrum
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Observação Dourada | Revisão do evento de erro do classificador Arbitrum
Autor: Golden Finance Jason
** Jinjin Finance Blockchain, 10 de junho ** Um bug no código classificador da Arbitrum esta semana causou uma breve interrupção da capacidade da rede de enviar transações em lotes, e as transações não puderam ser confirmadas na cadeia principal. A vulnerabilidade foi corrigida e a função de envio de lote de transações foi restaurada. Em 10 de junho, a Fundação Arbitrum divulgou o relatório de análise pós-fato sobre o bug do classificador Arbitrum. Em seguida, vamos revisar e ver por que esse evento de bug não causou a perda de fundos do usuário.
Linha do tempo do evento de erro do Classificador Arbitrum
Às 06h04min53s do dia 7 de junho de 2023, o emissor do lote não conseguiu atualizar sua exibição de estado L1 devido a um problema temporário com o nó L1 do classificador Arbitrum. Devido a um problema de causa raiz, o classificador Arbitrum continuou tentando consultar o estado de seu número de bloco de visualização L1 anterior. Isso significa que, mesmo depois que o problema temporário do nó L1 for resolvido, o publicador do lote continuará tentando consultar o estado do antigo número do bloco L1 e o nó L1 não terá mais seu estado porque não é um nó de arquivo.
Às 09h38min28s do dia 7 de junho de 2023, o anunciante do lote da Arbitrum parou de publicar transações porque atingiu o limite máximo configurado de transações na fila (256), que é o mesmo que o limite do mempool. Se esse limite não for atingido, a postagem em massa continuará normalmente.
Às 11h09 do dia 7 de junho de 2023, devido a lotes não publicados, foi acionado um alerta no contrato inteligente do Sequencer Inbox para verificar a existência de novos lotes e um aviso foi enviado ao canal Slack.
Às 11h10, a falta de lançamentos de lote recentes acionou um alerta baseado em log e enviou um alerta de nível crítico para o canal Slack.
Às 11h13, um membro da equipe da comunidade iniciou o PagerDuty com um membro da equipe SRE, que prontamente reconheceu o incidente e começou a responder.
Às 11:19:02 da manhã, a equipe do SRE reiniciou o batch poster, mas devido ao limite máximo de transações em fila mencionado anteriormente, o batch poster foi impedido de publicar transações. A equipe SRE notou esse problema e começou a mudar para um provedor L1 RPC terceirizado na tentativa de atenuar o problema.
Às 11h24min16s, 5 minutos após o início do pôster do lote, ele atualizou a visualização do estado L1 e publicou o primeiro lote de transações.
Às 11h25min09s, a configuração do pôster de lote foi alterada para usar um provedor L1 RPC terceirizado e reiniciada porque a equipe SRE já havia começado a fazer essa alteração e não notou o lote. Após uma reinicialização, as transações em lote continuam a ocorrer.
Às 11h30min21s da manhã, 5 minutos após o início do pôster do lote, a visualização do estado L1 foi atualizada, o que fez com que o estado L1 ficasse fora de sincronia, o que também era a causa raiz do problema. O estado L1 foi atualizado para o número do bloco final 17428199, mas usou o último nonce 178078, correspondente ao bloco mais recente no momento, em vez do bloco final armazenado em seu estado, resultando na limpeza de todas as transações enfileiradas no Redis Exceto, porque o Redis considera essas transações como confirmadas.
Às 11h30min26s, o anunciante do lote postou um novo lote. O Redis depende da exibição do estado L1 para determinar o que publicar, mas neste ponto a fila do Redis está vazia, conforme declarado anteriormente, o estado L1 está incorreto e um lote foi publicado com um número aleatório no estado 178078, mas para Determinar o lote a ser publicado, usando um número de bloco irrelevante 17428199, resultando na publicação de um lote antigo com um número de série 229209, que na verdade foi publicado às 11:24:16 antes e, em seguida, o pôster do lote reiniciou a inicialização. Como o lote antigo 229209 já foi publicado, a transação L1 enviada pelo lote foi revertida.
Às 11h36min35s, o endereço do anunciante do lote ficou sem Ether porque não reembolsou a taxa de gás, então parou de publicar. Este é um mecanismo intencional para evitar que o anunciante do lote consuma todo o gás armazenado no custo do lote de recuperação.
Às 11h46, um membro da equipe Nitro recebeu uma ligação para resolver um problema de software com a recuperação em lote.
Por volta das 11h58, a Arbitrum começou a receber relatórios de que alguns usuários descobriram que havia um problema com o classificador (transmitindo transações recém-classificadas para nós RPC), porque cada vez mais transações ordenadas eram devido a problemas de postagem em lote, em vez de postagem para a cadeia, esse problema afeta principalmente os clientes de feed com conexões de Internet ruins ou alocação de memória insuficiente, pois é mais provável que caiam e tenham problemas de reconexão. A Arbitrum recomenda que os usuários que executam vários nós RPC executem uma retransmissão de alimentação local para reduzir a largura de banda externa necessária.
Às 12h03, a Arbitrum removeu o limite de taxa de alimentação da Cloudflare para aliviar o problema de os clientes atingirem o limite de taxa ao tentar se reconectar após serem desconectados devido a uma conexão com a Internet.
Às 12h05, a Arbitrum removeu todos os limites de taxa do Cloudflare para permitir maior utilização de RPC público para aqueles cujos nós estavam tendo problemas para manter conexões com o feed.
Às 12h12min09s, o pôster de lote com defeito foi encerrado e o armazenamento de fila do Redis foi limpo para remover o estado incorreto.
Às 12h12min40s, o pôster do lote começou na versão antiga v2.0.14 e não houve problema de raiz.
Às 12h21min56s, o primeiro lote de pôsteres recém-abertos foi bem-sucedido, e eles estão sendo exibidos continuamente desde então.
Lições aprendidas sobre o evento de erro do classificador Arbitrum
Esta falha foi causada por um bug no poster do lote. O próprio sequenciador não foi afetado ou interrompido e continuou processando as transações durante todo o processo. Os relatórios de que o sequenciador ficou sem fundos estão incorretos. O mecanismo de financiamento da Arbitrum consiste em duas carteiras, a saber: a carteira "sequencer" e a carteira "gas-refunder". Somente quando o sequenciador conseguir liberar o lote com sucesso, ele será reembolsado. Falha, fundos e os problemas relacionados não foram causados pelo sequenciador ficando sem fundos, portanto, nenhum fundo do usuário estava em risco.
A Arbitrum limpará as opções de configuração que foram adicionadas na solução temporária. Posteriormente, planeja reavaliar os problemas de tempo limite do cliente e do servidor do sequenciador para melhorar a confiabilidade da rede no caso de atrasos nas transações. Uma nova "v2.1.0-beta .2" versão beta. Além disso, o Arbitrum criará uma página de status da rede pública para reduzir a confusão se houver problemas com o serviço.
Este artigo é referenciado no site oficial da Fundação Arbitrum