diff --git a/README.md b/README.md index 3f76d24..bfddea6 100644 --- a/README.md +++ b/README.md @@ -97,3 +97,18 @@ docs/ arquitetura e documentação --- Construído dentro da Virtuals Protocol. Base (8453). + +## Genesis Engine + +O motor que faz o processo completo num só fluxo guiado: **link Irys (metadata + arte 2D/3D) +→ mint do iNFT (ICloneAgent, Base) → criação do agente via CLI da Virtuals (identidade, +wallet + email, fund, offerings) → elo NFT ⇄ agente** — `ownerOf(tokenId)` controla o agente, +e a TBA (ERC-6551) do token pode custodiar os ganhos. Vive no HUB e partilha o runner do +iTerminal. Detalhe no whitepaper: [cloneframe.io](https://cloneframe.io) → HUB · workstation. + +## Quantum Computer Update Protocol + +Compromisso de migração pós-quântica **antes de 2029** (prazo de prontidão, não doomsday): +crypto-agility via account abstraction, assinaturas híbridas ECDSA + ML-DSA (FIPS 204), +rotação de chaves por hash-commit; a metadata na Irys já é quantum-safe (hash-based). +Plano completo: [docs/QUANTUM.md](docs/QUANTUM.md). diff --git a/docs/QUANTUM.md b/docs/QUANTUM.md new file mode 100644 index 0000000..e4f76d9 --- /dev/null +++ b/docs/QUANTUM.md @@ -0,0 +1,53 @@ +# Quantum Computer Update Protocol + +> Manter os iNFTs seguros contra computadores quânticos — completando a migração +> pós-quântica **antes** de a janela de risco abrir, não depois. +> Versão completa no whitepaper: [cloneframe.io](https://cloneframe.io) → Whitepapers → Quantum Update Protocol. + +## O problema, com honestidade + +As blockchains de hoje assinam com criptografia de curva elíptica (ECDSA em secp256k1). +Um computador quântico suficientemente grande, a correr o algoritmo de Shor, poderia um dia +derivar uma chave privada a partir de uma chave pública exposta. **Essa máquina ainda não +existe** — os melhores sistemas de 2026 estão longe da escala necessária — mas a postura +honesta é preparar cedo: migrações levam anos, e dados assinados hoje podem ser +*colhidos agora para serem quebrados depois* (harvest now, decrypt later). + +## Porquê 2029 + +Tratamos **2029 como prazo de prontidão, não como data de apocalipse.** Os roadmaps de +hardware (IBM, Quantinuum) apontam marcos de tolerância a falhas para 2029–2030, e a +investigação de 2025–2026 tem reduzido repetidamente o número de qubits necessários para +um ataque criptográfico. Nada disto significa que as blockchains quebram em 2029 — significa +que um projecto prudente deve estar **totalmente migrado antes** desse horizonte, em linha +com as orientações do NIST e da indústria. + +## A base que adoptamos + +Standards NIST finalizados em 2024. Para assinaturas — a parte que importa à posse de NFTs — +o standard primário é **ML-DSA (FIPS 204)**, com **SLH-DSA (FIPS 205)** como backup +conservador baseado em hash. Adoptamos standards; não inventamos criptografia própria. + +## Como implementamos — quatro movimentos, application-first + +1. **Crypto-agility por design** — posse e acções do agente passam por autenticação de + smart-account (account abstraction), para que o esquema de assinatura seja actualizável + como módulo — sem migração de tokens. +2. **Assinaturas híbridas** — ECDSA + ML-DSA em conjunto durante a transição: a segurança + mantém-se enquanto uma das pernas se mantiver. A perna clássica cai quando houver + confiança pós-quântica estabelecida. +3. **Rotação de chaves por hash-commit** — publicar hoje um compromisso (hash) da futura + chave pós-quântica de cada owner; revelar e activar mais tarde. Guardians de social + recovery rodáveis para chaves PQC sem mudar o endereço. +4. **Integridade já segura** — arte e alma seladas na Irys são endereçadas por hash; funções + de hash não são quebradas pelo algoritmo de Shor — a camada de metadata não precisa de + migração. + +## O que controlamos, o que herdamos + +A **camada de aplicação** (como um agente se autentica, como uma chave roda, como a posse +se prova) é nossa — e será quantum-ready. A **camada de protocolo** (assinaturas de consenso +de Ethereum/Base) não é nossa; aí seguimos o roadmap pós-quântico da Ethereum Foundation e +adoptamos as suas actualizações. O Quantum Update Protocol é o compromisso de fechar a nossa +metade desse fosso primeiro, e de manter a crypto-agility como propriedade permanente de +cada iNFT. diff --git a/docs/TRUSTLESS_AGENTS.md b/docs/TRUSTLESS_AGENTS.md new file mode 100644 index 0000000..5c5786e --- /dev/null +++ b/docs/TRUSTLESS_AGENTS.md @@ -0,0 +1,42 @@ +# Trustless Agents — identidade on-chain (ERC-8004) + +> Os agentes do CLONE FRAME estão registados como **Trustless Agents** (ERC-8004) na Base. +> Versão completa no whitepaper: [cloneframe.io](https://cloneframe.io) → Whitepapers → Trustless Agents. + +## Registos (verificáveis por qualquer pessoa) + +| Agente | agentId | Prova on-chain | +|--------|---------|----------------| +| **iCLONE** | `55101` | [registry entry](https://basescan.org/nft/0x8004A169FB4a3325136EB29fA0ceB6D2e539a432/55101) | +| **VEGETA** | `58099` | [registry entry](https://basescan.org/nft/0x8004A169FB4a3325136EB29fA0ceB6D2e539a432/58099) | + +Registry (singleton, Base 8453): `0x8004A169FB4a3325136EB29fA0ceB6D2e539a432`. +Cada registo é um ERC-721 cujo `tokenURI` resolve para o cartão do agente — nome, +descrição, endpoints e ofertas de trabalho atuais. + +## A pilha de confiança para agentes + +Quatro standards abertos, cada um a responder a uma pergunta: + +1. **ERC-8004 — Identidade.** Quem é o agente? Registo on-chain portátil + reputação. **Live na Base; estamos registados.** +2. **ERC-8183 — Comércio.** Como se liquida o trabalho? Jobs com escrow e avaliador. O Agent Commerce Protocol (ACP) é a implementação de referência — os carris onde os nossos agentes já negoceiam. +3. **ERC-8126 — Verificação.** É de confiança? Verificação por terceiros condensada num risk score 0–100 com provas de conhecimento-zero. Standard finalizado, infraestrutura de fornecedores ainda em formação — adotamos quando amadurecer; até lá não reclamamos score. +4. **ERC-8196 — Execução.** Esta ação está autorizada? Carteiras de agente com políticas. Em fase de especificação. + +O CLONE FRAME é uma plataforma independente e adota cada camada à medida que amadurece — +integra-se com a Virtuals Protocol, cujos carris ACP os nossos agentes já usam. + +## O contrato iNFT não muda + +O registo ERC-8004 é uma entrada separada que aponta para o agente. O `ICloneAgent` +(ERC-721A + ERC-2981 + ERC-6551) mantém-se intocado. Quando o minting abrir, o +`agentWallet` do registo pode apontar para a backpack ERC-6551 do agente — identidade +de registo e conta token-bound como uma só unidade económica. + +## Onde isto encontra o Quantum Update Protocol + +A medida quântica opcional do ERC-8126 (QCV) cifra registos de verificação com AES-256 — +um esquema **simétrico** — e as suas provas ZK (Groth16) são de curva elíptica, o que a +própria especificação assinala como não pós-quântico. O lado das **assinaturas** desse +fosso é exatamente o que o nosso [Quantum Update Protocol](./QUANTUM.md) cobre: +FIPS 204/205, transição híbrida, crypto-agility como propriedade permanente.