$$\rightleftharpoonup{xx}$$
$$\longleftharp{xx}$$,
$$\longrightharp{xx}$$,
Todos os experimentos foram conduzidos exclusivamente usando conjuntos de dados de intrusão de rede de referência públicos (UNSW-NB15, CIC-IDS-2017 e Bot-IoT), que contêm registros de tráfego de rede sem informações pessoais ou médicas identificáveis. Os conjuntos de dados foram usados de acordo com suas respectivas licenças e termos de uso. Como não houve participantes humanos, amostras de pacientes ou dados pessoais identificáveis envolvidos, não foi necessário aprovação ética institucional nem consentimento informado.
Visão geral do Quadro Proposto
Esta seção apresenta a proposta de estrutura de detecção e prevenção de intrusão em duas camadas para proteger ambientes IoMT. A estrutura integra uma rede BiLSTM Estendida para detecção de intrusões espaço-temporais com uma camada de blockchain leve para registro à prova de adulteração e mitigação automatizada. Ao contrário das abordagens convencionais de IDS, que focam exclusivamente na precisão da detecção, a arquitetura proposta é projetada para suportar simultaneamente detecção em tempo real, responsabilidade forense e conformidade regulatória, requisitos essenciais em sistemas de saúde. O fluxo de trabalho geral e a arquitetura do framework de detecção de intrusão BiLSTM–Blockchain proposto para redes IoMT são ilustrados na Figura 1.

Figura 1. Arquitetura do framework proposto de detecção de intrusão BiLSTM–Blockchain estendido para redes da Internet das Coisas Médicas. Representação esquemática da estrutura proposta mostrando os fluxos de trabalho de treinamento e implantação. No fluxo de trabalho de treinamento, dispositivos da Internet das Coisas Médicas (IoMT) geram tráfego de rede que passa por pré-processamento de dados e engenharia de recursos antes de serem analisados pelo modelo Bidirecional de Memória Prolongada de Curto Prazo (BiLSTM) com atenção temporal. Os parâmetros do modelo são otimizados por meio de computação da função de perda e treinamento iterativo. No fluxo de trabalho de implantação, o modelo treinado realiza a detecção de intrusão de acordo com a função de decisão definida na Equação 13. Eventos de intrusão detectados são encaminhados para o módulo blockchain, onde são realizados registros imutáveis, isolamento de nós e geração de alertas por parte dos administradores. BiLSTM, Memória Bidirecional de Curto Prazo Longo; IoMT, Internet das Coisas Médicas. Por favor, clique aqui para ver uma versão ampliada desta figura.
Dispositivos IoMT geram fluxos de dados heterogêneos compostos por tráfego de rede, metadados de dispositivos e sinais relacionados ao paciente. Tais entradas brutas são frequentemente ruidosas, redundantes e inconsistentes, tornando-as inadequadas para treinamento direto do modelo. Portanto, um pipeline de pré-processamento é aplicado para garantir a qualidade e a estrutura dos dados antes de introduzi-los no modelo BiLSTM Estendido. O pseudocódigo detalhado de pré-processamento é fornecido no Algoritmo 1 (Arquivo Suplementar 1), que descreve o pipeline de pré-processamento aplicado aos fluxos de dados IoMT antes do treinamento BiLSTM Estendido (pseudocódigo no Arquivo Suplementar 1; implementação no Arquivo Suplementar 2). A arquitetura completa do BiLSTM Estendido está resumida no Algoritmo 2 (Arquivo Suplementar 1).
Fluxo de Trabalho de Reprodução End-To-End
O estudo completo pode ser reproduzido usando os passos abaixo. Software e hardware estão listados na Configuração Experimental, e o código suplementar cobre cada etapa.
Obtenha os conjuntos de dados → baixe o UNSW-NB15. Use os arquivos UNSW_NB15_training-set.csv e UNSW_NB15_testing-set.csv. Baixe CICIDS2017. Use os cinco arquivos diurnos do Machine LearningCSV (de segunda a sexta-feira). Baixe Bot-IoT. Use os arquivos de subconjunto de 5 % UNSW_2018_IoT_Botnet_Full5pc_1_to_4. Estudos anteriores de detecção de intrusão geralmente se baseavam em conjuntos de dados de referência como KDD Cup 9914; no entanto, este estudo utiliza os conjuntos de dados mais recentes UNSW-NB15, CICIDS2017 e Bot-IoT para representar melhor o tráfego de rede contemporâneo. Processe cada conjunto de dados separadamente. O conjunto de dados UNSW-NB15 está disponível na Universidade de New South Wales em https://research.unsw.edu.au/projects/unsw-nb15-dataset (última modificação: 8 de fevereiro de 2024). O conjunto de dados CICIDS2017 está disponível no Instituto Canadense de Cibersegurança em https://www.unb.ca/cic/datasets/ids-2017.html (lançado: julho de 2017). O conjunto de dados Bot-IoT está disponível na Universidade de New South Wales em https://research.unsw.edu.au/projects/bot-iot-dataset (última modificação: 5 de fevereiro de 2024). Todos os conjuntos de dados foram acessados em maio de 2025 para este estudo.
Pré-processar os dados → remover registros corrompidos. Preencha valores faltantes usando meios de conjunto de treinamento. Aplique a redução de ruído EMA (α = 0,3). Normalize as características para [0,1] usando estatísticas do conjunto de treinamento. Códigos de etiqueta e códigos categóricos. Construa janelas deslizantes (T = 20, passada = 1). Essas etapas de pré-processamento suportam uma detecção robusta de intrusões ao reduzir o ruído e melhorar a qualidade das representações do tráfego de rede para IDSs baseados em aprendizado de máquina15,16.
Selecione características (AQU-IMF-RFE) → Classifique características por informação mútua. Refinar com o Aquila Optimizer. Aplicar RFE de Floresta Aleatória com validação cruzada 10 vezes. Mantenha os recursos finais. Essa estratégia híbrida de seleção de características segue o conceito mais amplo de combinar técnicas complementares de detecção deintrusões 17 e é implementada usando a estrutura AQU-IMF-RFE desenvolvida em nosso trabalhoanterior 18.
Treine o modelo → Para cada conjunto de dados, os dados foram particionados aleatoriamente em conjuntos de treinamento (80%) e de teste (20%) usando uma semente aleatória fixa de 42. Vinte por cento da partição de treinamento foi ainda reservada como conjunto de validação. Construa o BiLSTM Estendido. Treine usando perda binária ponderada de entropia cruzada e o otimizador Adam (taxa de aprendizado = 0,001, tamanho do lote = 64, máximo de 50 épocas, com parada antecipada). Salve o modelo treinado. O uso de modelos de aprendizado profundo temporal é bem adequado para tráfego heterogêneo doIoMT 19. O fluxo completo de treinamento do modelo está resumido no Algoritmo 3 (Arquivo Suplementar 1). Os pesos finais das classes foram calculados automaticamente a partir das distribuições de classes do conjunto de treinamento de acordo com as Equações 19 e 20. Os pesos de classe resultantes foram os seguintes: UNSW-NB15:
,
; CICIDS2017:
,
; e Bot-IoT (subconjunto de 5%):
,
. O grande valor de wn para o conjunto de dados Bot-IoT reflete a severa sub-representação de amostras benignas na partição de treinamento do subconjunto de 5%.
Implante a blockchain → inicie a cadeia de Prova de Autoridade (PoA). Implante o contrato inteligente e anote seu endereço. Autorize as contas do gateway. Execute o cliente de modo que cada intrusão detectada seja registrada e acione isolamento e alertas. O fluxo completo de detecção, registro de blockchain e mitigação é resumido no Algoritmo 4 (Arquivo Suplementar 1). A camada blockchain foi implementada usando o cliente go-ethereum (Geth) versão 1.13.15 para operar a rede PoA com permissões, o compilador Solidity (solc) versão 0.8.19 para compilação e implantação de contratos inteligentes, e a biblioteca web3.py versão 6.15.1 para comunicação entre o IDS e a rede blockchain.
Avalie → teste o modelo no conjunto de teste estendido. Calcule precisão, precisão, recall, pontuação F1 e taxa de falsos positivos. Gravar latência e throughput. Verifique a integridade do livro-razão da blockchain. O fluxo completo de avaliação é resumido no Algoritmo 5 (Arquivo Suplementar 1). A latência de detecção (Td) foi medida imediatamente antes da chamada de inferência do modelo até o momento em que as probabilidades previstas foram retornadas. A latência de mitigação de ponta a ponta (Td +T b) foi medida do mesmo ponto de partida até a conclusão da transação correspondente de criação de blocos na blockchain. A taxa de transferência foi calculada como o número total de janelas de teste pré-processadas processadas pelo pipeline completo de detecção e registro dividido pelo tempo de relógio de parede decorrido necessário para uma única passagem completa pelo conjunto de testes de cada conjunto de dados. A carga de trabalho consistia nas partições de teste janelas, preservando a distribuição original benigna para intrusão. Janelas maliciosas também geravam a sobrecarga de registro de blockchain, enquanto janelas inofensivas assumiam apenas o custo de detecção de intrusões.
Gerar figuras e tabelas → plotar as curvas de precisão e perda, matriz de confusão e gráficos de avaliação comparativa. Construa as tabelas de comparação. O fluxo completo de geração de figuras e tabelas está resumido no Algoritmo 6 (Arquivo Suplementar 1). O código-fonte completo desenvolvido sob medida usado para gerar todas as figuras e tabelas é fornecido no Arquivo Suplementar 2. Em particular, o script figures.py reproduz as figuras do manuscrito diretamente dos resultados experimentais salvos (por exemplo, histórico de treinamento e arquivos de matriz de confusão), enquanto os scripts restantes geram os dados processados e métricas de desempenho usadas para construir as tabelas reportadas.
A Figura 2 mostra o fluxo de dados em nível de implementação entre os módulos IDS e blockchain. A BiLSTM Estendida produz uma decisão por janela (Equação 13); em uma classificação maliciosa, o cliente gateway constrói e assina uma transação e a submete via web3/JSON-RPC ao smart contract PoA, que adiciona um bloco ligado por hash (Equação 14) ao livro contámbulo imutável e emite eventos (BlockCreated, NodeIsolated e AdminAlert) que acionam o isolamento do nó e alertas de administrador.

Figura 2. Interação em nível de implementação entre módulos de detecção de intrusão e blockchain. Diagrama de fluxo de trabalho ilustrando a comunicação entre o sistema de detecção de intrusão e os componentes da blockchain. O modelo BiLSTM Estendido classifica cada janela de entrada e aplica a regra de decisão definida na Equação 13. Quando uma intrusão é detectada, o cliente gateway gera e assina uma transação que é transmitida por Web3.py/JSON-RPC para o contrato inteligente Proof-of-Authority (PoA). O contrato adiciona um bloco ligado por hash ao livro-razão imutável de acordo com a Equação 14 e emite eventos BlockCreated, NodeIsolated e AdminAlert que acionam ações de contenção e notificação. IDS, Sistema de Detecção de Intrusões; BiLSTM, Memória Bidirecional de Curto Prazo Longo; Procuração, Prova de Autoridade; JSON-RPC, Notação de Objetos em JavaScript–Chamada de Procedimento Remoto. Por favor, clique aqui para ver uma versão ampliada desta figura.
Representação dos Dados
Vamos considerar R como o fluxo bruto de tráfego do IoMT. Após o pré-processamento, cada registro
bruto é mapeado em um vetor de características d-dimensional normalizado (Equação 1):
(1)
Aqui, f (⋅) é a função de transformação de características que mapeia registros brutos em um vetor de características normalizado em d dimensões. Seja a rede IoMT composta por um conjunto de nós (Equação 2):
N = {n 1 , n2, ... ,n k} (2)
Cada nó n j ∈ R produz um fluxo de dados em série temporal (Equação 3):
(3)
Aqui, xt é o vetor de características no tempo t, com d características (por exemplo, tamanho do pacote, tipo de protocolo, endereço de origem/destino) comumente observadas no tráfego de redes de saúde da Internet dasCoisas 19. O conjunto de rótulos correspondente é (Equação 4):
(4)
Aqui, yt=0 representa o tráfego normal e yt =1 denota uma intrusão.
Pré-processamento de dados
O pipeline de pré-processamento inclui as seguintes etapas, que abordam desafios comuns de qualidade de dados e segurança associados ao tráfegoIoMT 20:
Limpeza de Dados e Tratamento de Valor Faltante:
Um registro era identificado como corrompido e removido antes da imputação se satisfesse qualquer uma das seguintes condições explícitas: (i) todos os campos de características no registro estavam faltando (ou seja, o registro inteiro era nulo), ou (ii) o registro continha um valor não finito (infinito positivo ou negativo) em qualquer campo numérico após coerção do tipo. A segunda regra remove entradas inválidas, como aquelas produzidas por divisão por zero durante o cálculo de características de fluxo (por exemplo, valores infinitos de vazão decorrentes de fluxos de duração zero). Após a remoção dos registros corrompidos, os valores restantes ausentes foram imputados por meio da substituição média calculada por característica, por conjunto de dados e apenas da partição de treinamento; Os meios resultantes foram aplicados aos conjuntos de treinamento, validação e teste para evitar vazamento de informações. A imputação não foi condicional à classe, e as médias não foram agrupadas entre conjuntos de dados.
Redução de ruído temporal:
A redução de ruído temporal foi realizada usando um filtro de média móvel exponencial por característica (EMA) aplicado ao longo do eixo temporal. A forma recursiva (causal ) yt = α·xt + (1 − α)·yt−1 foi usada, com fator de suavização α = 0,3, implementada via a função ewm do pandas com ajustar=Falso. Cada característica foi suavizada de forma independente. Como um filtro exponencial (resposta infinita ao impulso), a EMA não possui janela fixa ou tamanho de kernel; O fator de suavização α é o único parâmetro que governa o grau de suavização e a memória efetiva do filtro.
Normalização Min–Max:
A normalização min–max foi aplicada para escalar cada característica até a faixa [0,1] usando a transformação x′=(x−min)/(max−min+ε), onde ε = 1 × 10−8. As estatísticas mínima e máxima eram calculadas por característica, por conjunto de dados e apenas a partir da partição de treinamento; Essas estatísticas de treinamento armazenadas foram então aplicadas para normalizar os conjuntos de treinamento, validação e teste, prevenindo o vazamento de informações ocultas. Durante a inferência, valores de características que ficam fora do alcance de treinamento foram reduzidos ao intervalo [0,1].
Codificação de Características Categóricas:
As características categóricas eram convertidas para forma numérica usando codificação de rótulos. Isso foi aplicado a todas as variáveis categóricas: no UNSW-NB15, os campos proto, serviço e estado; no Bot-IoT, o campo proto; CICIDS2017 não contém campos categóricos entre as características selecionadas. A codificação foi implementada com o LabelEncoder ajustado por variável.
Janelas Temporais para Aprendizado Sequencial:
O fluxo de características pré-processado foi segmentado em sequências de comprimento fixo usando uma janela deslizante de comprimento T = 20 passos de tempo com um passo de s = 1. Cada janela gerada foi validada antes da inclusão. Uma janela era aceita apenas se ela contivesse exatamente T = 20 passos de tempo consecutivos e todos os valores das características fossem finitos. Fluxos menores que T = 20 registros não produziam janelas. Essa configuração (T = 20, s = 1, 95% de sobreposição) foi aplicada de forma consistente em todos os experimentos e conjuntos de dados. O fluxo completo de pré-processamento é resumido no Algoritmo 1 (Arquivo Suplementar 1).
O objetivo do pré-processamento é permitir um mapeamento preditivo das sequências de entrada para rótulos de intrusão (Equação 5).
(5)
parametrizado por θ, isso prevê se um evento é benigno ou malicioso.
Seleção de Recursos Usando AQU-IMF-RFE
A seleção de características foi realizada usando AQU-IMF-RFE, um método híbrido que integra Informação Mútua (MI), o Aquila Optimizer (AO) e a Eliminação de Características Recursivas (RFE), introduzido em nosso trabalhoanterior 18. O método opera em três etapas. Na primeira etapa, a informação mútua entre cada característica e o rótulo da classe é calculada para obter uma classificação inicial de relevância. Na segunda etapa, o Aquila Optimizer realiza uma busca global sobre subconjuntos de características candidatos usando suas quatro estratégias de otimização. No terceiro estágio, o subconjunto refinado é passado por Eliminação de Características Recursivas com validação cruzada 10 vezes usando um estimador de Floresta Aleatória (RF).
O Aquila Optimizer foi configurado com um tamanho populacional de 100, um máximo de 10 iterações, um fator de exploração de 0,1, uma taxa de aprendizado de 0,1 e um fator de atração de 0,005. Aplicado independentemente a cada conjunto de dados, AQU-IMF-RFE manteve 14 recursos para o UNSW-NB15, 24 para CICIDS2017 e 12 para Bot-IoT. O pseudocódigo completo é fornecido no Arquivo Suplementar 1, e os subconjuntos de características selecionados estão listados na Tabela 4.
| Tabela 4A. Recursos Selecionados Retidos para o UNSW-NB15 |
| S. Não. | Característica | Tipo | Categoria |
| 1 | dur | Numérico (float) | Básico |
| 2 | sbytes | Numérico (inteiro) | Básico |
| 3 | Taxa | Numérico (float) | Básico |
| 4 | dload | Numérico (float) | Básico |
| 5 | sinpkt | Numérico (float) | Tempo |
| 6 | Dinpkt | Numérico (float) | Tempo |
| 7 | Sjit | Numérico (float) | Tempo |
| 8 | TCPrtt | Numérico (float) | Tempo |
| 9 | Sinaca | Numérico (float) | Tempo |
| 10 | ackdat | Numérico (float) | Tempo |
| 11 | smean | Numérico (inteiro) | Conteúdo |
| 12 | ct_srv_src | Numérico (inteiro) | Conexão |
| 13 | ct_dst_src_ltm | Numérico (inteiro) | Conexão |
| 14 | ct_srv_dst | Numérico (inteiro) | Conexão |
| Tabela 4B. Características selecionadas mantidas para CICIDS2017 |
| S. Não. | Característica | | |
| 1 | Porto de destino | | |
| 2 | Duração do Fluxo | | |
| 3 | Comprimento total dos pacotes forwarding | | |
| 4 | Comprimento Total dos Pacotes Reversos | | |
| 5 | Comprimento Máximo de Pacote Encaminhado | | |
| 6 | Comprimento Máximo de Pacote Reverso | | |
| 7 | Média do Comprimento dos Pacotes Invertido | | |
| 8 | Pacotes de Fluxo | | |
| 9 | Tempo Máximo de Inter-Chegada do Fluxo | | |
| 10 | Total de Tempo Inter-Chegada Avançado | | |
| 11 | Comprimento do cabeceio para frente | | |
| 12 | Comprimento do cabeçalho invertido | | |
| 13 | Pacotes Diretos por Segundo | | |
| 14 | Comprimento Máximo do Pacote | | |
| 15 | Média do Comprimento do Pacote | | |
| 16 | Desvio padrão do comprimento do pacote | | |
| 17 | Variância do comprimento do pacote | | |
| 18 | Tamanho médio do pacote | | |
| 19 | Tamanho médio dos segmentos para trás | | |
| 20 | Bytes Diretos do Subfluxo | | |
| 21 | Subfluxo de bytes retroativos | | |
| 22 | Bytes iniciais da janela encaminhados | | |
| 23 | Bytes iniciais da janela ao contrário | | |
| 24 | Média do comprimento do pacote para frente | | |
| Tabela 4C. Recursos Selecionados Retidos para Bot-IoT |
| S. Não. | Característica | Tipo | |
| 1 | seq | Numeric | |
| 2 | Média | Numeric | |
| 3 | StdDev | Numeric | |
| 4 | min | Numeric | |
| 5 | Max | Numeric | |
| 6 | srate | Numérico (float) | |
| 7 | drate | Numérico (float) | |
| 8 | N_IN_Conn_P_SrcIP | Numérico (inteiro) | |
| 9 | N_IN_Conn_P_DstIP | Numérico (inteiro) | |
| 10 | Proto | Categórico (codificado) | |
| 11 | state_number | Numérico (inteiro) | |
| 12 | Taxa | Numérico (float) | |
Tabela 4: Recursos selecionados pelo método de seleção de características AQU-IMF-RFE. Esta tabela lista os subconjuntos finais de características selecionados pelo framework de seleção de características AQU-IMF-RFE para os conjuntos de dados UNSW-NB15, CICIDS2017 e Bot-IoT. Nomes de características, tipos de dados e categorias funcionais são fornecidos quando aplicável.
Configuração Experimental
Todos os experimentos foram realizados em um servidor Dell PowerEdge R740 equipado com um processador Intel Xeon Silver 4214 operando em uma frequência base de 2,20 GHz, com 12 núcleos físicos, 24 threads lógicas, 16,5 MB de cache e uma velocidade Intel Ultra Path Interconnect (UPI) de 9,6 GT/s. O servidor estava configurado com 128 GB de RAM, um SSD de estado sólido (SSD) de 512 GB e operava no Microsoft Windows 11. A pilha de software compreendia Python 3.12.7, TensorFlow 2.16.1, scikit-learn 1.8.0, pandas 3.0.2 e NumPy 2.4.4. A camada blockchain foi implementada na mesma estação de trabalho usando uma rede Ethereum PoA. A comunicação entre o IDS e a blockchain era realizada via JSON-RPC usando o cliente go-ethereum (Geth) versão 1.13.15, o compilador Solidity (solc) versão 0.8.19 para compilação e implantação de contratos inteligentes, e a biblioteca Web3.py versão 6.15.1. O tempo de treinamento reportado, a latência de inferência e o throughput foram medidos nessa configuração de hardware e software.
Arquitetura e Treinamento em Modelos
O modelo BiLSTM Estendido constitui o componente central de detecção do framework, baseando-se em abordagens anteriores de detecção de intrusão baseadas em aprendizado desenvolvidas para ambientesIoMT 21. Estudos anteriores de detecção de intrusão destacaram tanto a importância de equilibrar o desempenho da detecção com a redução de falsoalarme 15 quanto os desafios únicos de aplicar métodos de aprendizado de máquina ao tráfego de redeem evolução 16. Arquiteturas colaborativas de detecção de intrusão em redes neurais demonstraram ainda o valor do aprendizado profundo de características sequencialmente para tráfego complexode rede 22. Enquanto modelos BiLSTM padrão capturam dependências temporais bidirecionais, o tráfego IoMT apresenta tanto padrões de rajada de curto prazo quanto dependências de longo alcance causadas por ataques multiestágio. Para resolver isso, o modelo proposto estende o BiLSTM com extração de características temporais, aprendizado temporal bidirecional aprimorado, conexões residuais e priorização temporal baseada em atenção. LSTMs bidirecionais (BiLSTM) superam essa limitação ao combinar estados ocultos para frente e para trás, permitindo uma representação temporal mais rica dos padrões de tráfego IoMT, conforme apresentado no Algoritmo 2 (Arquivo Suplementar 1).
Seja a sequência de entrada X(nj) = {x 1 , x2 , ... , xT }, onde cada xt ∈ Rd é um vetor de características pré-processado.
Extração de Características Temporais:
Uma convolução leve unidimensional é aplicada ao longo da dimensão temporal para enfatizar anomalias temporais de curto alcance (Equação 6):
U = φ (Conv1D(X(n j)), U = {u1,u 2, ..., uT } (6)
Aqui, φ(⋅) é uma função de ativação não linear e as características convolutórias ut são alimentadas para o BiLSTM.
A camada Conv1D extrai padrões temporais de curto alcance antes da modelagem de sequência bidirecional. Parâmetros completos de implementação são fornecidos no Arquivo Suplementar 3B.
Aprendizado LSTM Bidirecional Empilhado:
Os estados ocultos para frente e para trás são calculados como (Equação 7):
(7)
A representação final da BiLSTM é a concatenação de estados ocultos passados (para frente) e futuros (para trás) (Equação 8).
(8)
Duas camadas BiLSTM empilhadas modelam dependências temporais bidirecionais. Parâmetros arquitetônicos detalhados são fornecidos no Arquivo Suplementar 3B. Os detalhes da inicialização dos pesos são fornecidos no Arquivo Suplementar 3B.
Conexão residual e normalização
Após projeção linear para dimensões correspondentes, conexões residuais e normalização de camadas são aplicadas (Equação 9):

Projeção residual e normalização de camadas alinham as representações convolucionais e de características BiLSTM antes da atenção. Parâmetros detalhados de implementação são fornecidos no Arquivo Suplementar 3B.
Mecanismo de Atenção
Embora o BiLSTM forneça uma modelagem temporal forte, nem todos os passos de tempo contribuem igualmente para a previsão. Para enfatizar carimbos de tempo críticos (por exemplo, picos anômalos repentinos), é introduzido um mecanismo de atenção. Cada estado
oculto recebe uma pontuação de relevância αt para aumentar a precisão da detecção (Equação 10).

Aqui, Wa é um parâmetro treinável e os pesos de atenção satisfazem
O vetor de contexto c agrega os estados ocultos com base em sua importância aprendida (Equação 11):

O mecanismo de atenção agrega representações temporais em um vetor de contexto. Parâmetros detalhados de implementação são fornecidos no Arquivo Suplementar 3B.
Camada de Saída e Classificação
O vetor de contexto agregado é passado por uma camada totalmente conexa, seguido por uma ativação sigmoide para obter a previsão final (Equação 12):

Aqui, Wc e bc são parâmetros treináveis, e σ(·) é a função de ativação sigmoide que mapeia a saída para o intervalo [0,1]. Um limiar é aplicado para classificar o tráfego como benigno (
) ou intrusivo (
).
A regularização de abandono e o limiar fixo de classificação usado durante a inferência são descritos no Arquivo Suplementar 3B.
A arquitetura Extended BiLSTM é idêntica entre os três conjuntos de dados; apenas a dimensão da característica de entrada difere, assumindo valores de 14, 24 e 12 para UNSW-NB15, CICIDS2017 e Bot-IoT, respectivamente. Como a camada Conv1D mapeia qualquer entrada de dimensão para uma representação fixa de 64 canais, todas as camadas subsequentes são independentes do conjunto de dados, e apenas a forma de entrada e a contagem de parâmetros Conv1D variam com . A arquitetura completa camada por camada está resumida na Tabela 5, com as contagens de parâmetros expressas em termos de d; Os totais resultantes são 184.641, 186.561 e 184.257 parâmetros treináveis para D = 14, D = 24 e D = 12, respectivamente.
| S. Não. | Camada (Tipo) | Forma de Saída | Parâmetros Treináveis | Função de Ativação |
| 1 | Entrada | (20, d) | 0 | — |
| 2 | Conv1D (64 filtros, tamanho do núcleo = 3, mesmo preenchimento de volume) | (20, 64) | 192d + 64 | ReLU |
| 3 | Camada 1 de LSTM bidirecional (64 unidades por direção) | (20, 128) | 66,048 | tanh / sigmoid |
| 4 | Camada 2 de LSTM bidirecional (64 unidades por direção) | (20, 128) | 98,816 | tanh / sigmoid |
| 5 | Projeção Residual Densa | (20, 128) | 8,320 | Linear |
| 6 | Adição Residual | (20, 128) | 0 | — |
| 7 | Normalização de Camada (eixo = −1, ε = 1 × 10⁻³) | (20, 128) | 256 | — |
| 8 | Atenção Temporal (Wa ∈ R¹²⁸×¹) | 128 | 128 | Softmax |
| 9 | Camada Densa Oculta | 64 | 8,256 | ReLU |
| 10 | Desistência (p = 0,3) | 64 | 0 | — |
| 11 | Camada de Saída Densa | 1 | 65 | Sigmoide |
Tabela 5: Arquitetura camada por camada do modelo de Memória Bidirecional Estendida de Curto Prazo Longo. Esta tabela resume a arquitetura do modelo proposto de Memória Bidirecional Estendida de Curto Prazo (BiLSTM), incluindo tipos de camadas, dimensões de saída, contagens de parâmetros treináveis e funções de ativação.
O software e o ambiente computacional usados para todos os experimentos são resumidos na Tabela 6.
| Componente | Versão / Especificação |
| Sistema Operacional | Janelas |
| Plataforma de Servidor | Dell PowerEdge |
| CPU | Processador de 64 núcleos |
| RAM | 128 GB |
| Armazenamento | SSD de 512 GB |
| Python | 3.12.7 |
| NumPy | 2.4.4 |
| Pandas | 3.0.2 |
| scikit-learn | 1.8.0 |
| TensorFlow / Keras | 2.16.1 |
| Web3 (cliente blockchain) | 6.15.1 |
| conta eth- | 0.1 |
| Compilador de Solidity (solc) | 0.8.19 |
| go-ethereum (Geth) | 1.13.15 |
Tabela 6: Software e ambiente computacional usados para implementação e avaliação do framework proposto. Esta tabela resume as especificações de hardware, componentes de software, ferramentas de blockchain e números de versão usados para pré-processamento de dados, seleção de recursos, treinamento de modelos, implantação de blockchain e avaliação de desempenho.
Decisão de Intrusão e Resposta Automatizada
A detecção de intrusão em ambientes de saúde só é eficaz se seguida de resposta rápida e mitigação. A Camada de Detecção de Intrusão converte a probabilidade prevista em uma decisão. Formalmente, a decisão de intrusão no passo temporal t é representada da seguinte forma (Equação 13):

Aqui,
é a probabilidade prevista de intrusão no tempo t e
é o limiar de classificação.
Uma vez detectada uma intrusão, a Camada de Detecção de Intrusão se conecta diretamente com o módulo blockchain, que realiza registro imutável, mitigação automatizada e aplicação de segurança em circuito fechado. Detalhes do evento, incluindo informações de origem, informações de destino e recursos de tráfego selecionados, são registrados em um novo bloco blockchain. Contratos inteligentes executam ações de mitigação em tempo real, como isolamento de nós e alertas de administradores. Essa arquitetura em malha fechada permite que os resultados da detecção de intrusão sejam direcionados diretamente para os mecanismos de prevenção, minimizando assim a latência de mitigação. Assim, a Camada de Detecção de Intrusão serve como a ponte entre a detecção temporal usando o modelo BiLSTM Estendido e a resposta segura usando tecnologia blockchain, completando a funcionalidade de ponta a ponta do framework proposto.
Registro Forense Baseado em Blockchain
Embora o modelo BiLSTM Estendido permita a detecção de intrusões em tempo real, armazenamento seguro e auditoria verificável de eventos de intrusão são igualmente críticos em ambientes de saúde IoMT. Mecanismos tradicionais de registro centralizado são vulneráveis a manipulações e comprometem a rastreabilidade forense. Para enfrentar essa limitação, o framework proposto incorpora um módulo blockchain leve que garante imutabilidade, descentralização e resposta automatizada baseada em contratos inteligentes.
Cada evento de intrusão detectado gera um bloco que é adicionado à blockchain. Um bloco Bi é definido da seguinte forma (Equação 14):

Aqui, Hi é o hash criptográfico dos dados do evento, carimbo de tempo e resultado da previsão, Ti é o carimbo de tempo, Di contém características selecionadas do evento de intrusão, Sigi é a assinatura digital, e PrevHash vincula o bloco ao bloco anterior, garantindo imutabilidade.
Esse design garante resistência a adulteração porque qualquer modificação de Di ou Ti altera o hash do bloco e quebra a integridade da cadeia. Também oferece auditoria porque todas as anomalias detectadas são armazenadas permanentemente e verificáveis. A mitigação automatizada é suportada por meio de contratos inteligentes que executam ações pré-definidas, como isolamento de nós e alertas de administrador. A descentralização é alcançada por meio de múltiplos gateways IoMT mantendo o livro-razão distribuído, eliminando assim um único ponto de falha.
A geração de blocos utiliza a função de hash criptográfico Keccak-256, a primitiva nativa de hash do ambiente Ethereum/Solidity (invocada através do keccak256 do Solidity). Para cada bloco de intrusão, o hash do bloco é calculado da seguinte forma:

Aqui, Di é o resumo da característica do evento, Ti é o carimbo de tempo, e PrevHash é o hash do bloco anterior. Os campos são concatenados usando a codificação compactamente compacta do Solidity (abi.encodePacked) antes do hash, produzindo um digest de 256 bits.
O mesmo cálculo do Keccak-256 é usado pela rotina de verificação em cadeia, que recalcula cada hash de bloco a partir de seus campos armazenados e confirma que ele corresponde ao valor registrado, validando assim a integridade da cadeia. O Keccak-256 foi selecionado porque é o algoritmo padrão de hashing resistente a colisões usado nativamente dentro dos contratos inteligentes Ethereum. O contrato inteligente foi desenvolvido em Solidity e compilado usando o compilador Solidity (solc) versão 0.8.19. Foi implantado em uma rede privada Ethereum Proof-of-Authority (PoA) operada usando a versão 1.13.15 do Geth. A rede blockchain foi configurada com quatro nós validadores usando o protocolo de consenso Clique Proof-of-Authority, um ID de cadeia de 9848, um período de bloco de 5 s e um limite de gás de bloco de 30.000.000. A comunicação entre o motor de detecção de intrusões BiLSTM Estendido e a camada blockchain foi implementada usando a biblioteca Web3.py versão 6.15.1 através da interface HTTP JSON-RPC.
Mecanismo de Consenso do Ponto de Interesse
Como os sistemas IoMT em saúde são altamente sensíveis à latência, o framework proposto emprega um mecanismo de consenso PoA em vez do caro Proof-of-Work (PoW)23, que é computacionalmente caro. No PoA, um conjunto fixo de nós validadores confiáveis, como gateways hospitalares, autoriza transações, proporcionando tanto eficiência quanto resiliência.
A complexidade temporal da validação de blocos sob PoW pode ser expressa da seguinte forma (Equação 15):

Aqui, d representa a dificuldade de mineração.
Em contraste, a complexidade temporal do consenso PoA é dada da seguinte forma (Equação 16):

porque a validação requer apenas verificação por assinatura digital por nós validadores autorizados.
Como resultado, o PoA oferece operação de baixa latência adequada para alertas médicos em tempo real, eficiência energética ao evitar mineração computacionalmente intensiva e resiliência contra um número limitado de validadores maliciosos. A rede PoA foi configurada com quatro nós validadores, e essa configuração foi mantida fixa durante todos os experimentos para garantir medições consistentes de latência, avaliação de desempenho reproduzível e comparação justa entre todos os conjuntos de dados de benchmark.
Implementação de Blockchain e Operação de Contratos Inteligentes
O componente blockchain foi implementado em uma rede Ethereum autorizada operando sob o modelo de consensoPoA 24. A rede era executada usando o cliente go-ethereum (Geth) com o protocolo de consenso CliquePoA 25, no qual um conjunto de nós validadores autorizados (sealer) é responsável por produzir e validar blocos. O contrato inteligente de logging de intrusões (IoMTIntrusionLedger) foi escrito em Solidity e implantado nessa rede, seguindo arquiteturas de segurança IoT baseadas em blockchain para gerenciamento de eventos descentralizadoe seguro 26. Apenas contas de gateway autorizadas on-chain (via a função de controle de acesso do contrato) podiam enviar registros de invasão, consistentes com arquiteturas de contratos inteligentes de blockchain autorizadas para aplicações daInternet das Coisas 27. A camada blockchain foi implementada usando o cliente go-ethereum (Geth) versão 1.13.15 para operar a rede PoA com permissões, o compilador Solidity (solc) versão 0.8.19 para compilação e implantação de contratos inteligentes, e a biblioteca Web3.py versão 6.15.1 para comunicação entre o IDS e a rede blockchain.
Parâmetros detalhados de implantação e configuração da blockchain são fornecidos no Arquivo Suplementar 3C.
Cada registro de intrusão é assinado digitalmente antes de ser registrado no livro-caixa, apoiando a auditabilidade em saúde baseada em blockchain e a manutenção segura de registrosforenses 28. Procedimentos de geração e verificação de assinatura digital, incluindo ECDSA sobre a curva secp256k129,30, são descritos no Arquivo Suplementar 3D. Cada gateway possui um par de chaves Ethereum consistindo em uma chave privada de 256 bits (32 bytes) e a chave pública correspondente, da qual seu endereço de conta é derivado; a geração de chaves segue o procedimento padrão do Ethereum, usando uma chave privada aleatória de 256 bits criptograficamente segura, com a chave pública obtida pela multiplicação escalar secp256k1. Para criar uma assinatura, o cliente gateway calcula o digest de recurso de evento Di e o assina com sua chave privada usando o formato de assinatura de mensagens EIP-191, produzindo uma assinatura de 65 bytes composta pelos componentes r, s e v. A assinatura é enviada junto com o registro de intrusão. A verificação é realizada on-chain pelo contrato inteligente: usando a pré-compilação EVM ecreach, o contrato recupera o endereço do signatário a partir do digest e da assinatura assinados e exige que ele seja igual ao endereço do gateway autorizado que enviou a transação. Se o endereço recuperado não corresponder a um gateway autorizado, a transação é rejeitada. Isso vincula cada entrada do livro maior a um gateway autorizado específico e impede registros de intrusões não autorizadas ou falsificadas.
Contratos inteligentes são acionados automaticamente após a detecção
de intrusão, garantindo resposta em tempo real sem necessidade de intervenção manual (Equação 17):
(17)
O módulo blockchain opera em paralelo com o classificador BiLSTM Estendido. Uma vez detectada uma anomalia: (i) o evento é rotulado e classificado pelo BiLSTM, (ii) um bloco é gerado, assinado e anexado ao livro-razão da blockchain, e (iii) contratos inteligentes aplicam políticas de resposta automática.
O contrato inteligente de registro de intrusões (IoMTIntrusionLedger) mantém um livro-razão apenas anexo dos blocos de intrusão e um registro de contas de gateway autorizadas, além de expor as funções resumidas na Tabela 7. O contrato impõe dois papéis de acesso por meio de modificadores: onlyAdmin (o administrador que faz a implantação) e onlyGateway (contas autorizadas a enviar registros de intrusão). O estado consiste no mapeamento de autorização do gateway, no array do bloco-razão e na cabeça atual da cadeia (o hash do bloco mais recente).
| S. Não. | Função / Componente | Tipo | Acesso | Lógica |
| 1 | construtor | Construtor | — | Define o deployer como administrador e o autoriza como gateway inicial. |
| 2 | setGateway (endereço, bool) | Função | onlyAdmin | Adiciona ou remove uma conta de gateway autorizada; emite GatewayUpdated. |
| 3 | recordIntrusion(nodeId, patientId, attackClass, probabilityBp, dataDigest, signature, isolate) | Função | onlyGateway | Calcula Hi = Keccak-256(Di ∥ Ti ∥ probabilidade ∥ PrevHash); verifica a assinatura ECDSA do gateway em Di via ecrecover; anexa o bloco ao livro-caixa; avança a cabeça da corrente; emite BlockCreated, opcionalmente NodeIsolated e AdminAlert. Retorna Hi. |
| 4 | verifyChain() | Função de visualização | Público | Recalcula o hash de cada bloco a partir de seus campos armazenados e verifica a ligação PrevHash; retorna verdadeiro apenas se toda a cadeia for consistente (detecção de adulteração). |
| 5 | ledgerLength() | Função de visualização | Público | Retorna o número de blocos no livro-razão (ledger). |
| 6 | _recoverSigner(hash, sig) | Função Interna | — | Divide a assinatura de 65 bytes em (r, s, v) e recupera o endereço de assinatura via pré-compilação ecreole. |
| 7 | BlockCreated / NodeIsolated / AdminAlert / GatewayAtualizado | Eventos | — | Emitido para ouvintes off-chain para registrar drives, isolamento de nós, alertas de administrador e atualizações do registro do gateway. |
| 8 | onlyAdmin / onlyGateway | Modificadores | — | Restringa funções ao administrador e aos gateways autorizados, respectivamente. |
Tabela 7: Funções, eventos e componentes de controle de acesso do contrato inteligente IoMTIntrusionLedger. Esta tabela resume as principais funções, eventos e modificadores de controle de acesso implementados dentro do contrato inteligente da blockchain com permissão. Esses componentes suportam autorização de gateways, registro de intrusões, verificação de blockchain, geração de eventos e mitigação automatizada.
A propriedade de imutabilidade da blockchain decorre diretamente da Equação 14, onde qualquer modificação em dados de eventos ou carimbos de data invalida a cadeia de hash. Assim, o blockchain oferece integridade dos dados, rastreabilidade e auditabilidade para sistemas de saúde por meio de registros forenses imutáveis. Os registros de intrusão de pacientes e dispositivos permanecem inalterados após armazenados, cada bloco se conecta de forma segura ao bloco anterior, permitindo a reconstrução cronológica de eventos, e administradores ou reguladores de saúde podem verificar incidentes de intrusão sem risco de falsificação.
Função de Perda e Otimização de Modelos
O modelo BiLSTM Estendido proposto aborda o problema de classificação binária de distinguir entre eventos normais de tráfego e intrusão em redes IoMT. Para orientar o processo de treinamento, é adotada uma perda binária de entropia cruzada (BCE), que é bem adequada para saídas probabilísticas da camada de ativação sigmoide. Para um conjunto de dados com N amostras, a perda é definida da seguinte forma (Equação 18):
(18)
Aqui,
é o rótulo de verdade fundamental da i-ésima sequência de entrada (0 = benigno, 1 = intrusão), e
é a probabilidade prevista de intrusão.
A estrutura opera como uma linha de classificação em duas etapas. O primeiro estágio realiza a detecção de intrusão binária: o BiLSTM Estendido produz uma saída
sigmoide e aplica o limiar τ = 0,5 para classificar cada janela como benigna ou intrusiva (Equações 12,13), treinada com perda binária ponderada de entropia cruzada. Um segundo estágio pode realizar categorização de ataques, na qual janelas identificadas como intrusões são passadas para um classificador multiclasse que atribui a categoria específica de ataque usando uma camada softmax de saída treinada com entropia cruzada categórica. O presente estudo foca e avalia a etapa de detecção binária. Os dois estágios compartilham a mesma espinha dorsal de extração de características do BiLSTM Estendido (Conv1D, BiLSTM, camadas residuais, de normalização e de atenção); Eles diferem apenas em sua camada de saída (sigmoid para detecção e softmax para categorização) e na função de perda correspondente. A fase de detecção binária e a etapa de categorização multiclasse foram treinadas e avaliadas sob as mesmas partições de dados, sementes aleatórias e condições de treinamento descritas acima.
Embora o tráfego IoMT seja frequentemente desequilibrado, uma perda binária ponderada de entropia cruzada é usada para penalizar a classificação incorreta da classe minoritária. Os pesos de classe são calculados usando o número de amostras de intrusão Np, o número de amostras benignas Nn e o número total de amostras N (Equações 19,20):


A ponderação garante que o modelo não seja tendencioso para a classe dominante de tráfego benigno e permaneça sensível a eventos raros, porém críticos, de intrusão.
A perda binária ponderada de entropia cruzada é dada da seguinte forma (Equação 21):
(21)
O treinamento foi realizado usando mini-lotes do tamanho 64. No início de cada época, as amostras de treinamento eram embaralhadas aleatoriamente antes de serem particionadas em lotes, de modo que a composição em lotes variava entre épocas e o modelo não via exemplos em ordem fixa. Os lotes não eram explicitamente balanceados ou estratificados por classe; em vez disso, cada lote refletia a distribuição natural de classes do conjunto de treinamento, e o desequilíbrio de classes era tratado por meio da perda binária de entropia cruzada ponderada por classe (Equações 19–21). O subconjunto de validação reservado da partição de treinamento permaneceu fixo entre épocas e não foi embaralhado nos lotes de treinamento.
Os pesos das classes na perda binária ponderada de entropia cruzada não foram definidos manualmente, mas foram calculados automaticamente para cada conjunto de dados a partir das contagens de classes do conjunto de treinamento, de acordo com as Equações 19 e 20. Para o conjunto de dados UNSW-NB15, os pesos de classe resultantes foram
para a classe normal e
para a classe de intrusão. Para o conjunto de dados CICIDS2017, os pesos resultantes da classe normal
e
da classe de intrusão. Para o conjunto de dados Bot-IoT (subconjunto de 5%), os pesos resultantes da classe normal
e
da classe de intrusão.
Estratégia de Treinamento e Otimização
O modelo BiLSTM Estendido foi treinado usando mini-lotes de tamanho B = 64 com perda binária ponderada de entropia cruzada, o otimizador Adam e parada precoce baseada na perda de validação. O treinamento foi limitado a 50 épocas, e a parada precoce foi aplicada com paciência K = 5. Se a perda de validação não melhorasse por cinco épocas consecutivas, o treinamento era interrompido e os pesos do modelo eram restaurados para aqueles da época com menor perda de validação. Assim, 50 épocas representavam o orçamento máximo de treinamento em vez de uma duração fixa de treinamento. Uma probabilidade de abandono de 0,3 foi aplicada para regularização. Os ajustes arquitetônicos incluíam 64 filtros Conv1D, 64 unidades LSTM por direção, um comprimento de janela de T = 20 e uma passada de s = 1. A estratégia de treinamento adotada é resumida no Algoritmo 3 (Arquivo Suplementar 1). As equações de atualização Adam usadas para otimização são fornecidas no Arquivo Suplementar 3A.
O otimizador Adam foi configurado com uma taxa de aprendizado de
, uma taxa de decaimento no primeiro momento (β1) de 0,9, uma taxa de decaimento no segundo momento (β2) de 0,999 e uma constante de estabilidade numérica (
) de 1 × 10-7. Nenhuma opção adicional de otimizador foi utilizada, e nenhum decaimento de peso ou clipping de gradiente foi aplicado.
Geração de Alertas e Mitigação Automatizada
A detecção sozinha é insuficiente em redes IoMT sensíveis à latência, onde a resposta rápida é crítica para garantir a segurança do paciente. A Camada de Geração e Mitigação de Alertas operacionaliza a decisão de intrusão tomada pelo modelo BiLSTM Estendido e pelo mecanismo de registro da blockchain. Se δt = 1, o módulo blockchain adiciona um novo bloco contendo os detalhes
da intrusão . Simultaneamente, um contrato inteligente é executado para acionar ações de mitigação (Equação 22):
(12)
Aqui, o BlockCreation garante um registro forense imutável do evento, o NodeIsolation (nj) coloca o nó IoMT comprometido para evitar danos adicionais, e o AdminAlert entrega notificações em tempo real aos administradores do sistema. Para operar esse pipeline de resposta de camadas duplas, o pseudocódigo é apresentado no Algoritmo 4 (Arquivo Suplementar 1).
Processamento de eventos por smart contract e mecanismos de resposta off-chain são descritos no Arquivo Suplementar 3E.
Cada entrada comprometida no livro-razão da blockchain é armazenada como um registro IntrusionBlock, cujos campos e formatos de dados estão listados na Tabela 8. O livro razão é um array apenas anexo desses registros, e a cabeça atual da cadeia armazena o hash do bloco adicionado mais recentemente.
| S. Não. | Campo | Tipo de Dado | Tamanho | Descrição |
| 1 | hashId | bytes32 | 32 bytes | Hash do bloco Hi = Keccak-256(Di ∥ Ti ∥ probabilidade ∥ PrevHash) |
| 2 | Carimbo de tempo | uint256 | 32 bytes | Tempo de criação de bloco Ti (segundos de época Unix, a partir do carimbo de tempo do bloco) |
| 3 | nodeId | bytes32 | 32 bytes | Identificador do nó IoMT nj |
| 4 | pacienteId | bytes32 | 32 bytes | Identificador de paciente/dispositivo (metadados forenses) |
| 5 | Classe de ataque | uint16 | 2 bytes | Código da categoria de ataque (0 = Normal, 1 = DDoS, 2 = Falsificação, ...) |
| 6 | probabilidadeBp | uint16 | 2 bytes | Probabilidade de intrusão prevista ŷ em pontos base (0–10000, ou seja, 0,00–100,00%) |
| 7 | dataDigest | bytes32 | 32 bytes | Resumo Di dos eventos selecionados se destaca |
| 8 | assinatura | Bytes | Variável (65 bytes) | Assinatura ECDSA Sigi do digest de eventos pelo gateway (r, s, v) |
| 9 | prevHash | bytes32 | 32 bytes | Hash do bloco anterior (PrevHash), ligando a cadeia |
| 10 | isolado | bool | 1 byte | Se o isolamento de nó foi acionado para esse registro |
Tabela 8: Estrutura do registro IntrusionBlock armazenado no livro-razão da blockchain. Esta tabela descreve os campos, tipos de dados, tamanhos de armazenamento e propósitos dos registros do livro razão da blockchain usados para armazenar eventos de intrusão. A estrutura suporta verificação de integridade criptográfica, rastreabilidade forense e mecanismos automáticos de resposta.
A latência total de mitigação pode ser expressa como a soma do atraso de detecção (Td) do modelo BiLSTM Estendido e do atraso de execução da blockchain (Tb) (Equação 23):
(23)
Análise de Complexidade Computacional
A eficiência do framework BiLSTM–Blockchain Estendido proposto é determinada tanto pelo custo computacional do modelo BiLSTM quanto pelo overhead introduzido pelo módulo blockchain. A estrutura proposta integra a detecção Estendida de BiLSTM com registro em blockchain para satisfazer os requisitos centrais de segurança da tríade de Confidencialidade, Integridade e Disponibilidade (CIA).
Seja o comprimento da sequência de entrada pré-processada T, a dimensão de característica d, e a dimensão oculta do BiLSTM h.
Para cada passo de tempo, um BiLSTM processa entrada de dimensão d com tamanho oculto h. Como é bidirecional (para frente + para trás) (Equação 24):
) (24)
Aqui, T é o comprimento da sequência (passos de tempo), d é a dimensão de característica de entrada, h é a dimensão de estado oculto
A camada de atenção calcula pesos de importância e agrega estados ocultos com complexidade (Equação 25).
(25)
que é linear tanto na sequência de comprimento T quanto na dimensão oculta h.
A complexidade total de detecção por sequência é, portanto, dada da seguinte forma (Equação 26):
(26)
demonstrando que a modelagem temporal domina o custo computacional, enquanto o mecanismo de atenção introduz apenas um overhead leve.
Para cada evento de intrusão detectado, o registro da blockchain realiza operações de hash, assinatura e anexação de blocos (Equação 27):
(27)
Para N eventos de detecção de intrusão, a complexidade combinada torna-se a seguinte (Equação 28):
(28)
que pode ser simplificado da seguinte forma (Equação 29):
(29)
porque o overhead da blockchain cresce linearmente com o número de eventos e permanece negligenciável em comparação com os cálculos de processamento de sequências.
A complexidade computacional é resumida nas Equações 24–29. A interpretação detalhada é fornecida no Arquivo Suplementar 3F.