KIX // The Shadow Layer

1. Desacoplamento entre Operação e Acesso

O princípio arquitetônico central do protocolo KIX baseia-se na separação estrita entre a camada de execução de software e a interface de acesso do usuário.

2. Motor de Execução (Core Lightning)

Para garantir a escalabilidade da rede e a viabilidade operacional em hardwares variados, o protocolo KIX adota o Core Lightning (CLN) como motor de execução preferencial.

• Otimização de Recursos: O CLN apresenta alta eficiência no consumo de memória (variando entre 50MB e 150MB de RAM). Esta característica viabiliza uma alta densidade de nós por hardware, superando implementações mais custosas do ponto de vista computacional.
• Escalabilidade Local (Soberania em Massa): A arquitetura suporta a execução simultânea de múltiplas instâncias isoladas de CLN conectadas a um único nó do Bitcoin Core local. Para esta topologia, exige-se a parametrização avançada do nó base (ajustes em rpcthreads e dbcache) e o uso mandatório de armazenamento em estado sólido de alta performance (SSD NVMe) para suportar as operações de entrada e saída (I/O) concorrentes dos bancos de dados locais.

3. Topologia Híbrida (Integração de Light Clients)

O protocolo padroniza a capacidade de operação descentralizada sem a obrigatoriedade da manutenção de um nó completo (Full Node) na ponta operacional.

• Light Clients via Plugins: Utilizando extensões nativas (como folgore ou sauron), a instância CLN é configurada para delegar a validação do estado da blockchain a um indexador remoto (Esplora).
• Minimização de Requisitos: Esta abordagem reduz a exigência de armazenamento da ponta de aproximadamente 1TB (necessário para o Initial Block Download) para menos de 1GB. Isso viabiliza o uso de Operadores KIX em hardwares de baixo custo ou legado, garantindo sincronização instantânea.

4. Infraestrutura Central de Indexação

Para cenários onde múltiplos nós leves dependem de um indexador comum, o protocolo estabelece requisitos estritos para a infraestrutura do servidor provedor (Esplora):

• Requisitos de Hardware: Exige-se o uso de servidores Bare Metal com alta contagem de núcleos de processamento, arranjos de armazenamento Enterprise NVMe (RAID) e capacidade massiva de memória primária (128GB a 256GB de RAM).
• Arquitetura de Cache: A memória RAM é alocada de forma intensiva para manter os índices (RocksDB) prontamente disponíveis. Implementa-se uma camada de proxy reverso (NGINX) configurada para armazenar em cache respostas a requisições redundantes (como estado do bloco atual), mitigando picos de demanda concorrente durante atualizações da rede.

5. Escalabilidade Horizontal e Orquestração (Nuvem)

Para implantações do KIX orientadas a serviços em nuvem (Cloud/SaaS) de grande escala, o provisionamento local via Docker Compose é substituído por arquiteturas baseadas em Kubernetes (K8s).

• Gestão de Estado Contínuo: A orquestração dos nós utiliza recursos de StatefulSets, garantindo que cada instância possua uma identidade persistente na rede e acesso a volumes imutáveis, prevenindo a corrupção do estado dos canais.
• Isolamento de Instâncias: A segurança criptográfica e a separação de tráfego entre diferentes operadores na mesma infraestrutura são garantidas por meio de segmentação via Namespaces e políticas estritas de rede (NetworkPolicies).

6. Perfis Oficiais de Implantação

A implementação do protocolo KIX é estruturada em quatro perfis arquitetônicos padronizados, permitindo a adequação do software à capacidade de infraestrutura e à necessidade de soberania de cada operador.