NIST FIPS 204 & 206 Bonsai Turbo O(1) Quantum Leap L2

Jamii: The Sovereign Post-Quantum Blockchain

Infraestrutura blockchain industrial para a era pós-quântica. Combina a segurança comprovada de curvas elípticas (Secp256k1) com algoritmos baseados em reticulados homologados pelo NIST (Falcon-512 / FIPS 206 e ML-DSA-65 / FIPS 204) em envelopes híbridos de Portão-E com Strong Binding. Operada sobre o motor de estado Bonsai Turbo O(1) e acelerada pelo Sequenciador de Camada 2 JAMII Quantum Leap.

Iniciar Validador Conhecer o Quantum Leap L2

Status do Projeto: Produção Pós-Quântica & L2 Sequencer

Maturidade industrial consolidada em Setembro/2026 com Falcon-512 nativo em C (FIPS 206), toolchain Zig multiplataforma, emaranhamento de contas e a especificação do Sequenciador Quantum Leap.

Falcon-512 CGO Homologado

Eliminação total de stubs e mocks. Integração do código oficial em C (github.com/algorand/falcon) com padrão NIST FIPS 206, gerando assinaturas ultra-compactas de 666 bytes e verificação em < 0.48 ms.

Emaranhamento Quântico (20B)

Compromisso Bi-Polar dual (QuantumEntanglement) de 20 bytes gravado no StateDB (jamiiAccount). Impede em nível de protocolo a injeção indevida de chaves PQC e sequestro de contas 0x legadas.

JAMII Quantum Leap L2

Sequenciador Soberano de Camada 2 com soft finality em ~10ms (porta :8546). Validação obrigatória do Portão-E em cada TX e liquidação em tempo constante O(1) na Verkle Tree da L1.

Hot-Reload & Governança

Rotação on-chain de identidades PQC via smart contract ValidatorRegistry.sol. O chassi do nó captura eventos EVM e atualiza a chave privada do consenso IBFT 2.0 em RAM sem reiniciar o processo.

Mandato PQC Estrito

Premissa soberana inegociável: allowClassicalTransactions: false ativado por padrão. Transações puramente clássicas sem componente pós-quântico são rejeitadas sumariamente no Ingress e no bloco.

Toolchain Zig 0.16 Universal

Cross-compilação CGO universal e limpa para Windows AMD64, Linux AMD64 e Linux ARM64 a partir de uma única estação de trabalho com zig cc, garantindo reprodutibilidade binária absoluta.

Diferenciais Tecnológicos (The Jamii Edge)

Inovações arquiteturais desenvolvidas para garantir escalabilidade global, resiliência quântica incondicional e I/O de milissegundos.

1. Identidade Unificada Shadowless & Emaranhamento Dual

Um único payload de 20 bytes mapeia para a mesma conta no World State, servindo de forma unificada tanto a endereços clássicos Ethereum (0x...) quanto soberanos (jamii1...). O Emaranhamento Quântico amarra imutavelmente as chaves clássica e PQC através de compromisso Bi-Polar, garantindo Zero-Migration UX com blindagem contra ataques de impersonação.

2. Bonsai Turbo (O(1) I/O nativo sobre PebbleDB)

Elimina a tradicional descida de árvore ($O(\log N)$ acessos a disco). O Jamii implementa o Bonsai Turbo sobre o PebbleDB em Go puro, assegurando acesso a contas e saldos em tempo constante $O(1)$ em RAM/LSM-Tree, relegando o cálculo e a escrita de raiz criptográfica para o segundo plano.

3. Portão-E Dual com Strong Binding (ECDSA ∧ PQC)

A assinatura é estruturada em envelope auto-descritivo (0x02). A transação só é válida se ambas as chaves aprovarem a mensagem vinculada com separação de domínio: BoundMessage = Keccak256(Msg || TradPK || QuantPK). Nenhuma transação puramente clássica é aceita por padrão.

4. Agilidade Criptográfica (Falcon-512 & ML-DSA-65)

A rede suporta paralelamente múltiplos algoritmos pós-quânticos padronizados pelo NIST: Falcon-512 (FIPS 206, alta densidade e assinaturas de 666 bytes) e ML-DSA-65 (FIPS 204 / Dilithium L3), permitindo transição e convivência fluida entre esquemas.

5. Trie Criptográfica Paralela (Verkle Homomórfica & SMT)

Suporte nativo a Verkle Tree com compromissos polinomiais IPA/Bandersnatch e SMT (Sparse Merkle Trie). A computação de provas e subárvores é paralelizada via semáforos e goroutines, explorando 100% dos núcleos de CPU disponíveis.

6. Ultra-Compact Skeleton (Bi-Polar Short IDs)

Redução de 81% no tráfego de rede P2P (DTS Engine). Blocos com milhares de transações trafegam identificadores compactos de 6 bytes (3 iniciais + 3 finais), permitindo que o bloco chegue antes do sinal de votação do consenso IBFT 2.0.

JAMII Quantum Leap: Sequenciador L2 Pós-Quântico

A Camada 2 Soberana projetada para desbloquear milhares de transações por segundo com latência em milissegundos e liquidação determinística O(1) na Verkle Tree da Camada 1.

Soft Finality em ~10ms > 98% Alívio de State Bloat Portão-E Obrigatório

Por que a L1 não deve processar cada micro-transação na escala global?

Enquanto a verificação criptográfica PQC na Jamii L1 consome microssegundos, a gravação de estado no disco (PebbleDB) para milhares de transações individuais representa o limite físico de I/O. Propagar centenas de milhares de assinaturas volumosas satura a banda P2P e incha o banco de dados. O JAMII Quantum Leap atua como a camada de execução de alta velocidade: processa micro-operações em memória, valida o Portão-E em cada requisição e ancora lotes inteiros de 500 a 1.000 transações na L1 através de uma única transação em tempo constante O(1) na Verkle Tree.

Fluxo Arquitetural do Sequenciador Quantum Leap:

Ingress RPC (:8546)

Recebe a transação L2, executa a verificação do Portão-E (Secp256k1 ∧ PQC) e retorna soft finality ao cliente em ~10ms.

Execução em Memória

Aplica a transação no StateDB volátil em RAM, atualizando saldos, nonces e computando a raiz da Verkle Tree local do sequenciador.

Empacotamento de Lote

Ao atingir 500 a 1.000 TXs (ou 1 segundo), consolida o lote, calcula a transição de estado e gera o payload criptográfico de liquidação.

Liquidação O(1) na L1

Submete a transação de lote para o contrato L2BatchVerifier.sol na Jamii L1, ancorando a nova raiz na Verkle Tree em tempo constante O(1).

A Fronteira Criptográfica: Esquemas Baseados em Funções de Hash

A Teoria da Redução Mínima de Hipóteses (Dan Boneh & Marcos Simplício) e a simbiose entre XMSS e SLH-DSA no ecossistema Jamii.

A Tese da Redução Mínima de Hipóteses

Qualquer assinatura digital pós-quântica (seja Falcon ou ML-DSA) já depende obrigatoriamente de uma função de hash para resumir a mensagem com separação de domínio: d = Hash(Context || Randomness || M). Portanto, a segurança de qualquer rede PQC já confia cegamente na resistência quântica do próprio hash. Esquemas puramente baseados em hash (HBS) eliminam hipóteses algébricas de reticulados, reduzindo as suposições matemáticas ao menor nível possível. O único ataque conhecido contra hashes de 256 bits é o algoritmo quântico de Grover (que ainda requer 2¹²⁸ operações, termodinamicamente inalcançável).

A Simbiose Perfeita: XMSS + SLH-DSA no L2

O XMSS (Stateful) produz assinaturas ultra-compactas (~1,6 KB), mas o reuso acidental de contador destrói a chave privada, tornando-o perigoso para carteiras comuns de usuários. O SLH-DSA (Stateless) não possui estado, mas gera assinaturas de ~7,8 KB que causariam saturação em redes L1. A Jamii resolve o paradoxo dividindo os papéis: usuários assinam na L2 com SLH-DSA compacto (sem risco de dessincronia), enquanto o Sequenciador e os Validadores L1 assinam lotes e votos de consenso com XMSS (infraestrutura servidora transacional dedicada).

Por que a Árvore Merkle não pode ser trocada por Verkle no HBS?

A Verkle Tree depende intrinsecamente de curvas elípticas homomórficas (como Bandersnatch) e compromissos polinomiais (IPA/KZG) para calcular seus nós em $O(1)$. Como toda curva elíptica é quebrável em tempo polinomial pelo Algoritmo de Shor em computadores quânticos, utilizar Verkle Tree dentro de uma assinatura PQC baseada em hash destruiria instantaneamente sua imunidade quântica. A árvore de Ralph Merkle permanece insubstituível na assinatura HBS porque baseia-se unicamente em funções de hash.

Por que a prova Merkle é diferente a cada transação do mesmo usuário?

No esquema HBS (XMSS e SLH-DSA), cada folha na base da árvore contém uma chave WOTS+ de uso estritamente único. Ao assinar uma transação, aquela folha específica é queimada permanentemente para evitar vazamento dos segredos intermediários. A transação seguinte é obrigatoriamente assinada pela folha subsequente, cujo caminho de nós vizinhos até a raiz pública é inteiramente diferente. A prova Merkle dinâmica é o mecanismo matemático que garante a unicidade e a inviolabilidade da chave.

Desempenho em Produção Distribuída: Super Carga Falcon-512

Resultados auditados em rede física de validadores sob flood massivo contínuo (67.000+ transações acumuladas), avaliando o algoritmo Falcon-512 homologado em C e ML-DSA-65 no consenso.

Throughput Sustentado

120.9 TPS

Vazão real de 37.166 TXs em 57 blocos contínuos auditados.

Pico de Vazão Efetiva

351 req/s

Capacidade de absorção instantânea no Ingress RPC.

Latência Cripto PQC

< 0.48 ms

Verificação Falcon-512 em CGO nativo (285 µs a 480 µs).

Redução de Envelope

80% Menor

Assinatura Falcon-512 (666B) vs ML-DSA-65 (3.309B).

Dimensão Arquitetural	Falcon-512 (NIST FIPS 206)	ML-DSA-65 (NIST FIPS 204)	Secp256k1 (Legado Clássico)
Resistência Quântica	NIST Nível 1 (Homologado)	NIST Nível 3 (Homologado)	Nula (Quebrável por Shor)
Throughput L1 Sustentado	120.9 TPS (Super Carga)	94.8 TPS	~15 TPS (Ethereum Base L1)
Pico de Ingress RPC	351 req/s	280 req/s	~100 req/s
Tamanho da Assinatura	666 bytes (~80% de redução)	3.309 bytes	65 bytes
Tamanho da Chave Pública	897 bytes	1.952 bytes	33 bytes / 64 bytes
Latência de Verificação	285 µs a 480 µs (< 0.5 ms)	380 µs a 540 µs	~60 µs
Footprint Médio por TX	~1.6 KB / TX (Alta densidade)	~4.2 KB / TX	~0.3 KB / TX
Consenso DTS IBFT 2.0	< 100ms (Votação e Quórum)	< 100ms	> 500ms
Cadência de Bloco (Pacing)	3.0s a 3.1s (Homogênea)	3.0s a 3.1s	12.0s (Ethereum)

Folga Operacional e Estabilidade

Do intervalo físico de 3.0s de cada bloco, o processamento de consenso, execução EVM e persistência PebbleDB consomem aproximadamente 100ms a 180ms. O restante representa tempo de pacing ocioso, garantindo que mesmo sob estresse severo os nós operem sem perda de pacotes ou saturação de CPU.

Resiliência com Watchdog Keep-Alive

O Watchdog emite sinais de status a cada 5 segundos. Caso algum validador oscile, as tabelas de quórum se autorregulam dinamicamente sem gerar bifurcações, mantendo 100% dos blocos finalizados em Round 0.

Documentação e Auditoria

Acesse as especificações técnicas detalhadas, artigos criptográficos e memoriais de arquitetura do ecossistema Jamii.

🏛️

Criptografia PQC Baseada em Hash (HBS)

quantum-leap/hash-cripto.md

🚀

JAMII Quantum Leap (Sequenciador L2)

quantum-leap/quantum-leap-plan.md

📜

Documentação Técnica (Arquitetura)

docs/DOCUMENTACAO_TECNICA.md

🧠

Memória Técnica Consolidada

MEMORIA_TECNICA.md

🛠️

Manual de Desenvolvimento

docs/MANUAL_DESENVOLVIMENTO.md

🏁

Plano Geral do Projeto

docs/PLANO_GERAL_PROJETO.md

⚡

Otimizações Jamii Turbo

docs/jamii_turbo_optimization.md

⚙️

Especificação de Gênesis & Parâmetros

docs/GENESIS.md

Garantias de Auditoria & Blindagem Criptográfica:

Falcon-512 CGO Homologado (FIPS 206)

Implementação de referência em C com detecção rigorosa de adulteração matemática (*tamper detection*).

Emaranhamento Quântico Anti-Impersonation

Compromisso Bi-Polar dual no StateDB blindando contas 0x contra injeção indevida de chaves PQC.

Consenso de Estado Determinístico (Verkle/SMT)

Garantia estrita de convergência via Trie Factory, Bonsai Turbo e indexação canônica por Payload.

Hot-Reload & Governança de Validadores

Rotação transparente de chaves PQC em tempo de execução através do contrato ValidatorRegistry.sol.

Começando

Gere sua identidade soberana, inicialize validadores ou implante os containers oficiais.

1. Geração de Identidade Soberana (PQC Keygen)

Gere a identidade criptográfica híbrida (Secp256k1 + Falcon-512 ou ML-DSA-65). O comando deriva automaticamente o mnemônico de 12 palavras (BIP-39/BIP-44) para recuperação segura:

Bash / Command Line

# Gera identidade padrão com Falcon-512 (FIPS 206 / alta densidade)
jamii keygen --algo Falcon512 --datadir ./data

# Ou com ML-DSA-65 (NIST FIPS 204 / Dilithium Nível 3)
jamii keygen --algo MLDSA65 --datadir ./data

# Rotação on-chain de identidade PQC (atualização transparente no consenso)
jamii rotate --datadir ./data

2. Inicialização Direta do Nó

Inicie o nó validador com o motor IBFT 2.0, DTS P2P e servidor JSON-RPC:

Bash / Command Line

# Inicialização do nó validador com RPC padrão (:8545)
jamii start --datadir ./data --config ./config.yaml

# Inicialização com rastreador detalhado de opcodes da EVM ativado
jamii start --datadir ./data --config ./config.yaml --enable-vm-tracer

3. Executando os Containers Docker

docker-run-node.sh

docker run \
  --name jamii-node \
  -v ./config.yaml:/config.yaml:ro \
  -v ./genesis.json:/genesis.json:ro \
  -v ./peers.json:/peers.json:ro \
  -v ./datadir:/datadir \
  -p 8545:8545 \
  -p 30303:30303 \
  -p 42000:42000 \
  -d magnoabreu/jamii-node:0.1.0-alpha

docker-run-archiver.sh

docker run \
  --name jamii-archiver \
  -v ./config.yaml:/config.yaml:ro \
  -v ./genesis.json:/genesis.json:ro \
  -v ./peers.json:/peers.json:ro \
  -v ./datadir:/datadir \
  -p 8556:8556 \
  -p 30310:30310 \
  -p 42020:42020 \
  -d magnoabreu/jamii-archiver:0.1.0-alpha