- O tempo de inatividade do IOTA Tangle na semana passada foi causado por um teste de spam externo.
- O teste foi provavelmente conduzido por uma empresa maior que pode estar interessada em adotar a IOTA.
Como relatado pela CNF, a IOTA mainnet ficou parada por mais de meio dia, de 12 a 13 de novembro. Enquanto havia rumores de uma possível causa para o tempo de inatividade do Tangle, no momento do evento só ficou claro que nenhum marco havia sido gerado pelo coordenador. Em um artigo publicado ontem no GitHub, a Fundação IOTA forneceu agora um relatório detalhado sobre os eventos.
De acordo com isto, o incidente ocorreu em 12 de novembro de 2020 às 19:45 UTC e foi totalmente resolvido em 13 de novembro de 2020 às 12:37 UTC. O motivo da paralisação do Tangle foi um teste de spam iniciado pela comunidade, pelo qual o teste foi coordenado antecipadamente com a Fundação IOTA. Como a organização por trás da IOTA afirma, “nenhuma mudança no software do nó” ou qualquer outro componente da rede foi responsável pelo incidente.
Durante o teste, a rede atingiu mais de 1,000 TPS. De acordo com a Fundação IOTA, a rede entrou em colapso durante a fase final do teste, quando “a infra-estrutura que hospedava alguns dos componentes críticos da rede atingiu seus limites de processamento IOPS” Em termos da causa, a Fundação IOTA explicou melhor:
A infra-estrutura e, posteriormente, o software implantado não foi capaz de processar todas as transações que vinham para a rede. Isto fez com que o coordenador emitisse marcos para as transações que não persistiram devido ao gargalo da IO acima mencionado.
Devido à carga sobre a rede como um todo, o coordenador não foi capaz de fofocar as transações necessárias para solidificar os marcos emitidos antes de ser interrompido, levando a rede inteira a não ser capaz de solidificar.
Para resolver o incidente, uma nova versão do Hornet foi lançada em 13 de novembro, e a infra-estrutura foi atualizada para a nova versão do software do nó. De acordo com a Fundação IOTA, o incidente e o evento de spam anterior ajudaram a refinar os “protocolos de resposta” internos. Também soube que “as restrições da IOPS na infra-estrutura ao redor do coordenador precisam ser melhoradas”.
Como resultado, foi criado um mecanismo de redundância para garantir o armazenamento de todas as transações enviadas de e para o coordenador. Além disso, foi implementado um mecanismo para garantir que o coordenador reaja ao estado da rede e interrompa automaticamente a saída de marcos em situações em que o coordenador esteja se aproximando do limite de recursos de hardware.
Detalhes do teste de spam da comunidade IOTA
Através do canal Discord da IOTA, um organizador do teste de spam também revelou mais detalhes sobre as especificações do teste. De acordo com isto, mais de 2,000 nós estávamo em uso. Em média, 1,892 nós fomo totalmente sincronizados durante o teste e distribuídos em 24 locais diferentes em todo o mundo.
Além de explicar o procedimento para o teste de spam, o organizador também sugeriu que poderia haver “um pouco mais atrás” do teste, especificamente uma empresa maior:
Houve 3 ondas, 5 minutos cerca de 600-750, 5 minutos de pausa para acalmar a rede e potencialmente voltar à sincronia para nós externos, 10 minutos cerca de 1000TPS, novamente 5 minutos de pausa e depois realmente 30 minutos 1800-2000 TPS foram planejados, mas aqui as métricas de monitoramento nos deixaram e o problema mencionado nos pegou.
Além destas estatísticas, que eu não acho muito interessante, talvez outra abordagem … não é mais emocionante pensar por que alguém faria tal teste de spam? Tanto por isso: Não apenas pelo gozo disso. Quer dizer, custa dinheiro, muito dinheiro, você não pode simplesmente aceitar estas ordens de magnitude de recursos. Não é legal quando você sabe que há um pouco mais por trás disso?! Futura adaptação incomming. Portanto, um pequeno agradecimento à minha empresa.
