# RFC ProtectChain-001 — ProtectChain: prova de anterioridade autoral ancorada e cofre de conteúdo consentido - **Status:** **Especificação Aberta (Open Specification)** — Rascunho v0.3 - **Versão:** 0.3 - **Data:** 2026-09-09 - **Organização:** **Global Innovation Technology LTDA** — GlobalCopyrights.org - **Autores:** | Autor | Papel | Identificador | |---|---|---| | **Orlando Tempobono** | Autor principal | ORCID [0009-0002-2533-7446](https://orcid.org/0009-0002-2533-7446) | | **Nelson Tempobono** | Coautor | — | | **Lucas Tempobono** | Coautor | — | | **Felipe Tempobono** | Coautor | — | | **Clara Tempobono** | Coautora | — | - **Contato:** contact@globalcopyrights.org - **Aplica-se a:** ProtectChain (rede) + integração com GlobalCopyrights.org (gcorg) - **Escopo de mercado:** **global/internacional**. A fundamentação é deliberadamente **agnóstica a jurisdição**: apoia-se em tecnologia universal (Ed25519, RFC 3161, OpenTimestamps/ Bitcoin, C2PA) e **não** depende de infraestruturas regionais de PKI (ex.: não usamos ICP-Brasil). - **Licença:** texto sob **CC BY 4.0**; implementação **livre de royalties**; marca **ProtectChain™** reservada. Ver §0 (Licença e uso). > **Changelog** > - **0.3:** promove o documento a **Especificação Aberta**; adiciona §0 (licença CC BY 4.0, > concessão de implementação livre de royalties, reserva de marca e regra de citação); registra > autoria nominal e ORCID; declara intenção de publicação (DOI/Zenodo e IETF Internet-Draft). > - **0.2:** adiciona §5A (assinatura de artefatos) e §8A (uso de IA na criação vs. proteção > anti-coleta como eixos independentes); remove qualquer dependência de ICP-Brasil; reforça escopo global. --- ## 0. Licença e uso (Especificação Aberta) A ProtectChain é publicada como **padrão aberto**: qualquer pessoa ou organização **PODE** implementá-la, estudá-la, redistribuí-la e construir produtos sobre ela, **desde que cite a fonte e os autores**. ### 0.1 Licença do texto — CC BY 4.0 Este documento é licenciado sob **Creative Commons Atribuição 4.0 Internacional (CC BY 4.0)** — https://creativecommons.org/licenses/by/4.0/ . Você **PODE** copiar, redistribuir, adaptar e usar comercialmente, **desde que** dê o crédito apropriado, indique se houve alterações e forneça um link para a licença. **Forma de citação recomendada:** > Tempobono, O.; Tempobono, N.; Tempobono, L.; Tempobono, F.; Tempobono, C. (2026). > *RFC ProtectChain-001 — ProtectChain: prova de anterioridade autoral ancorada e cofre de conteúdo > consentido*, v0.3. Global Innovation Technology LTDA / GlobalCopyrights.org. > ORCID: https://orcid.org/0009-0002-2533-7446 ### 0.2 Implementação — concessão livre de royalties Os autores concedem, de forma **irrevogável, mundial, não exclusiva e livre de royalties**, o direito de **implementar** o protocolo aqui descrito — incluindo operar nós, produzir software compatível e interoperar com a rede — sem necessidade de licença adicional ou pagamento. ### 0.3 Marca reservada **ProtectChain™** e os selos/identidade visual da **GlobalCopyrights.org** **NÃO** são licenciados por este documento e permanecem de titularidade da **Global Innovation Technology LTDA**. Implementações independentes **PODEM** declarar compatibilidade (ex.: *"compatible with the ProtectChain specification"*), mas **NÃO DEVEM** usar a marca de modo a sugerir origem, endosso ou certificação oficial sem autorização escrita. ### 0.4 Sem garantia O documento é fornecido "**no estado em que se encontra**", sem garantias de qualquer natureza. A adoção da especificação é de responsabilidade do implementador. ### 0.5 Publicação e identificadores - **Registro primário de autoria/data:** o próprio documento é registrado na **ProtectChain** e ancorado via **OpenTimestamps/Bitcoin** e **TSA RFC 3161** (dogfooding da própria tese). - **Identificador acadêmico:** pretende-se emitir um **DOI** (Zenodo) para citação formal. - **Trilha de padronização:** pretende-se submeter um **Internet-Draft** à IETF (via *Independent Submission Stream*, categoria Informational). Os autores reconhecem que a submissão à IETF exige a concessão de direitos ao **IETF Trust** (BCP 78/79), o que **coexiste** com a licença CC BY 4.0 aqui adotada. > As palavras-chave **DEVE**, **NÃO DEVE**, **DEVERIA**, **NÃO DEVERIA** e **PODE** > neste documento seguem o sentido do RFC 2119 (requisitos normativos). --- ## Abstract A **ProtectChain** é uma blockchain **permissionada** (privada, com nós autorizados) operada pela GlobalCopyrights, cujo propósito é produzir **prova de anterioridade** de obras autorais: atestar, de forma verificável e resistente a adulteração, que **um determinado conteúdo existia numa determinada data sob a autoria declarada por um determinado usuário**. Dois princípios a fundamentam: 1. **A obra nunca entra na chain.** A ProtectChain registra **apenas impressões digitais criptográficas (hashes) e metadados** — jamais o conteúdo do autor. A prova é sobre a *existência* do conteúdo, não uma cópia dele. 2. **A confiança não depende só de nós.** Como todos os nós iniciais pertencem ao mesmo operador, cada bloco é **ancorado em livros públicos independentes** (Bitcoin via OpenTimestamps e Autoridades de Carimbo do Tempo RFC 3161), tornando a data **inforjável mesmo pelo próprio operador**. A federação futura com nós de terceiros reforça a descentralização. A ProtectChain sustenta ainda um segundo produto: o **Cofre de Conteúdo** — o upload do autor é, por padrão, **inacessível a crawlers de busca e de IA**, e só se torna público/indexável por **ação consentida e explícita do autor**, ato esse **irreversível** e também registrado na chain. --- ## 1. Motivação O direito autoral nasce automaticamente com a criação (Convenção de Berna; Brasil: Lei 9.610/1998, art. 18 — a proteção independe de registro). O problema prático não é *ter* o direito, mas **provar autoria e anterioridade** num litígio. Serviços de "prova de anterioridade" resolvem isso gerando evidência datada. A fragilidade típica desses serviços é que a data depende do banco de dados do próprio provedor — que poderia, em tese, retroagir registros. A ProtectChain elimina essa fragilidade com **ancoragem externa** e prepara o terreno para **federação independente**, ao mesmo tempo em que **preserva o sigilo** da obra (nunca a expõe) e abre um novo produto de **proteção contra coleta não autorizada por IA/crawlers**. ## 2. Terminologia - **Registro (record):** conjunto de hashes + metadados de uma obra submetido à chain. NÃO contém o conteúdo. - **Bloco (block):** lote de registros selado, encadeado ao anterior por hash e assinado por um nó sealer. - **Nó (node):** servidor participante. Papéis: **sealer** (produz blocos) e **validator** (valida/co-assina). - **Âncora (anchor):** prova externa da existência de um bloco num livro público (Bitcoin/OTS ou TSA RFC 3161). - **Cofre (vault):** armazenamento do conteúdo do autor no gcorg, cifrado e não indexável por padrão. - **Liberação (release):** ato consentido e explícito do autor que torna uma obra pública/indexável — **irreversível**. - **Assinatura destacada (detached):** assinatura criptográfica sobre o *hash* do arquivo, guardada fora dele; funciona para **qualquer** formato e não altera o arquivo original. - **Assinatura embutida (embedded):** assinatura gravada **dentro** do arquivo, quando o formato a suporta (PDF/PAdES, Office/OOXML, C2PA para imagem/vídeo). - **Declaração de uso de IA (AI-usage disclosure):** metadado **opcional** em que o autor informa se/como usou IA como ferramenta na criação. É **transparência**, **nunca** condição para registrar. ## 3. Princípios de design 1. **Privacidade por construção.** O conteúdo do autor **NÃO DEVE** ser transmitido, armazenado ou derivável a partir da ProtectChain. Apenas `sha256`, `sha512` e metadados declarados trafegam. 2. **Prova, não posse.** Um registro prova que um arquivo com aquele hash existia numa data — não prova, por si só, a originalidade (isso é uma **autodeclaração** do autor, ver §10). 3. **Confiança em camadas.** A data de um bloco é sustentada por (a) assinatura do nó, (b) carimbo RFC 3161 de uma TSA independente, (c) ancoragem no Bitcoin. Comprometer a data exigiria quebrar as três — inclusive a mais forte, o Bitcoin. 4. **Poder no autor.** Todo conteúdo é privado por padrão; qualquer exposição é opt-in explícito, granular e auditável — e a irreversibilidade é comunicada antes do ato. 5. **Portabilidade dos nós.** Um nó **DEVE** rodar em hardware modesto (LXC) e ser autossuficiente, para viabilizar SP/CS/PI hoje e terceiros amanhã. ## 4. Arquitetura da chain ### 4.1 Topologia inicial Três nós próprios, um por sítio, para tolerância a falha geográfica: | Nó | Sítio | Papel inicial | |---|---|---| | `pc-sp` | São Paulo | validator (e sealer de contingência) | | `pc-cs` | cluster CS | **sealer** primário | | `pc-pi` | cluster PI | validator | No protótipo (fase 0) há **um único nó** (`pc-dev-dock`) em dev, exercendo sealer, para validar o software ponta a ponta antes de provisionar as LXCs dedicadas. ### 4.2 Estrutura canônica **Registro** — `record_hash` é o sha256 da forma canônica (campos separados por `\n`): ``` record\n \n \n \n \n \n \n ``` Campos: `work_ref` (id da obra no gcorg), `sha256`/`sha512` (hashes do arquivo do autor, calculados no gcorg), `declared_at` (data declarada de criação), `received_at` (instante UTC no nó), `cert_code`. Metadados extras opcionais vão em `payload` (JSON) — **nunca** o conteúdo. **Bloco** — encadeado e assinado: ``` merkle_root = raiz de Merkle (sha256 pareado) dos record_hash do lote block_hash = sha256( "block\n"\n\n\n\n\n ) signature = Ed25519( block_hash ) pelo nó sealer ``` O bloco **gênese** (índice 1) tem `prev_hash = 0×64` e nenhum registro. ### 4.3 Consenso — Proof-of-Authority (PoA) Somente nós **autorizados** (lista de chaves públicas mantida pela governança da GlobalCopyrights) produzem/validam blocos. O sealer designado sela o lote; validators **DEVERIAM** recomputar `block_hash`, checar o encadeamento e **co-assinar** (tabela `cosigns`), elevando a robustez de um bloco proporcionalmente ao nº de co-assinaturas independentes. PoA é adequado porque a identidade dos operadores é conhecida e auditável — não há necessidade de mineração/PoW. ### 4.4 Identidade e chaves Cada nó possui um par **Ed25519**; a chave privada **NÃO DEVE** deixar o nó. A pública identifica o nó na chain e permite verificação por qualquer terceiro. Rotação de chave **DEVE** ser registrada como evento na própria chain. ## 5. Ligação com outras chains (fundamento de confiança) A ProtectChain não vive isolada: ela **ancora** o resumo de cada bloco em sistemas que ela **não controla**, importando a imutabilidade deles. ### 5.1 OpenTimestamps → Bitcoin Para cada bloco, o `block_hash` é submetido ao **OpenTimestamps**, que o agrega (com milhares de outros do mundo) e o compromete na blockchain do **Bitcoin**. A prova (`.ots`) nasce *pendente* e **amadurece** em ~1–3h quando o bloco Bitcoin confirma. Resultado: provar que um `block_hash` (e, por Merkle, cada registro dentro dele) existia **antes** de um bloco Bitcoin específico — inforjável inclusive pelo operador. Custo: **zero** (não há transação própria nem taxa). ### 5.2 Carimbo do Tempo RFC 3161 (TSA) Em paralelo, o `block_hash` recebe um **carimbo do tempo assinado** por uma Autoridade de Carimbo do Tempo independente (fase 0: **FreeTSA**, gratuita). Vantagem: é **instantâneo** — cobre a janela enquanto o OpenTimestamps amadurece. RFC 3161 é um **padrão internacional**, verificável em qualquer país. Evolução: usar **múltiplas TSAs internacionais** independentes (redundância de jurisdições), sem depender de nenhuma PKI regional específica. **Não** adotamos ICP-Brasil ou equivalentes nacionais — o produto é global e a prova deve valer no mundo todo pela tecnologia, não por credenciamento local. ### 5.3 Disciplina de tempo (NTP / relógio atômico) Os nós **DEVEM** ter o relógio disciplinado por fontes atômicas de referência via NTP — recomendado **`ntp.br`** (Observatório Nacional, Hora Legal Brasileira) como primário e **`time.nist.gov`** (NIST-F2, EUA) + `pool.ntp.org` como redundância. Observação: a exatidão do relógio interno é para *precisão e citação*; a **inforjabilidade** da data vem das âncoras (§5.1/5.2), não do relógio. ### 5.4 Modelo de confiança em camadas ``` Assinatura do nó (Ed25519) → autenticidade/autoria do bloco + Co-assinaturas (federação) → descentralização + TSA RFC 3161 (independente) → data assinada, instantânea + OpenTimestamps / Bitcoin → data inforjável, pública = a data de um registro só cai se TODAS as camadas caírem juntas ``` ## 5A. Assinatura de artefatos (viabilidade por formato) "Assinar o arquivo do autor" e "registrar o hash" são coisas diferentes: **hash ≠ assinatura**. O hash prova *integridade* (é este conteúdo); a **assinatura** prova *autenticidade* (quem avaliza e quando) ao cifrar o hash com uma chave privada. Na ProtectChain, **o hash do arquivo já é assinado** (Ed25519 do nó) e carimbado/ancorado — ou seja, **produzimos uma assinatura digital destacada sobre o conteúdo, para qualquer formato**. ### 5A.1 Modelo base — assinatura DESTACADA (universal) — **NORMATIVO** O sistema **DEVE** tratar toda obra pela via destacada: calcula-se `sha256`/`sha512` do arquivo original (seja **vídeo, .docx, .xlsx, .pptx, .jpg, .png, .zip, .tar.gz, binário cru** — qualquer um), e a ProtectChain assina/ancora esse hash. Isso **não altera** o arquivo do autor e é uniforme para 100% dos formatos. É o alicerce e não depende do formato. ### 5A.2 Camada opcional — assinatura EMBUTIDA (por formato) — **OPCIONAL** Quando o autor quiser um arquivo **autocontido** e o formato suportar, o sistema **PODE** oferecer assinatura embutida: | Formato | Suporte | Padrão | |---|---|---| | PDF | ✅ | PAdES | | .docx/.xlsx/.pptx | ✅ | Assinatura OOXML (o pacote Office é ZIP com slot de assinatura) | | .jpg/.png/.mp4 (imagem/vídeo) | ✅ | **C2PA / Content Credentials** (ver §5A.4) | | .zip/.tar.gz/arbitrário | ❌ | não há padrão embutido → somente destacada | **Regra de integridade — NORMATIVO:** assinar de forma embutida **altera o arquivo e portanto seu hash**. O registro primário na chain **DEVE** ser sempre o hash do **original**; a versão assinada embutida é um **derivado**, com seu próprio hash, que **PODE** ser registrado como artefato vinculado. Nunca se substitui o original pelo derivado sem manter o vínculo. ### 5A.3 Assinante — quem avaliza — **INFORMATIVO** - **Nó (padrão):** a ProtectChain assina — prova "registrado na GlobalCopyrights/ProtectChain na data X". Zero fricção para o autor. - **Chave do autor (opcional, avançado):** o autor assina com chave própria — prova pessoal, ao custo de gestão de chaves. - Deliberadamente **não** adotamos autoridades de certificação **regionais** (ex.: ICP-Brasil) — a confiança vem da tecnologia universal e das âncoras públicas, válidas globalmente. ### 5A.4 C2PA / Content Credentials — item de estudo (ligado ao Cofre anti-coleta) O **C2PA** é o padrão de indústria (Adobe, Microsoft, BBC e outros) de **provência de conteúdo**: metadados **assinados** embutidos em imagem/vídeo dizendo origem, autoria e histórico de edição — incluindo **se e como IA foi usada**. É estratégico porque: - serve de **assinatura embutida** para mídia (foto/vídeo); - carrega a **declaração de uso de IA** (§8A) de forma padronizada e assinada; - conversa com o **Cofre** (§8): quando reservado, sinaliza "uso não autorizado para treino"; quando liberado, sinaliza a permissão — sempre por escolha do autor. Fica marcado como **estudo de fase 2/3**, sobre a base destacada já existente. ## 6. Federação e remuneração (fase 2+) Terceiros (pessoas/organizações) **PODERÃO** operar nós, mediante **cadastro e autorização prévios** pela governança (KYC do operador + aceite de termos + adição da chave pública à lista de autoridades). Um nó de terceiro: - Recebe e **co-assina** blocos, aumentando a independência da prova. - **PODE** ser **remunerado** por disponibilidade e co-assinações válidas, segundo um esquema de incentivo (ex.: pagamento por bloco co-assinado dentro de SLA de tempo/uptime), liquidado periodicamente. Regras de corte (slashing) para nó que assinar bloco inválido/divergente **DEVERIAM** existir para desincentivar má-fé. - **NÃO** tem acesso ao conteúdo das obras (apenas hashes/metadados) — a federação amplia a prova **sem** ampliar a superfície de exposição do conteúdo. Governança, tabela de remuneração e critérios de admissão serão objeto de **RFC ProtectChain-002**. ## 7. O que **não** trafega (garantia de sigilo) | Dado | Onde vive | Vai para a chain? | |---|---|---| | Arquivo/obra do autor | Cofre no gcorg (cifrado) | **NUNCA** | | sha256 / sha512 do arquivo | gcorg → chain | Sim (só o hash) | | Metadados declarados (título? autor_ref, datas, cert_code) | gcorg → chain | Sim (mínimos necessários) | | Dados pessoais sensíveis do autor | gcorg | **NÃO** (só um `author_ref` opaco) | Assim, mesmo um nó de terceiro (fase 2) ou qualquer pessoa lendo a chain **não consegue** reconstruir a obra nem identificar diretamente o autor — apenas verificar a existência/data. ## 8. Cofre de Conteúdo — proteção contra crawlers e IA (2º produto) Além de *provar*, a GlobalCopyrights **protege**: o conteúdo do autor não deve vazar para mecanismos de busca nem para coletores de treinamento de IA sem consentimento. ### 8.1 Privado por padrão Todo upload entra no **Cofre**: armazenamento **cifrado**, servido **apenas** sob autenticação do dono, **sem URL pública**, **sem** aparecer em sitemap/oEmbed/preview, com respostas carregando `X-Robots-Tag: noindex, noimageai, noai` e o arquivo fora de qualquer diretório rastreável. O objetivo declarado: **nem crawler de busca nem crawler de IA acessa o conteúdo** — evitando cópia e uso como "inspiração"/treinamento não consentido. ### 8.2 Camadas técnicas de bloqueio (defesa em profundidade) - **Autorização obrigatória** em toda entrega de arquivo (nada de link direto público). - **`robots.txt`** desautorizando a área do cofre + **`X-Robots-Tag`** por resposta. - **Sinais anti-IA** reconhecidos: `noai`/`noimageai`, **`ai.txt` / TDM Reservation Protocol (`tdmrep.json`)**, `llms.txt` marcando o conteúdo como **não** disponível. - **Bloqueio de user-agents** de coletores conhecidos (GPTBot, CCBot, Google-Extended, etc.) e *rate-limiting*/desafio a bots no perímetro (traefik/WAF). - **Marca d'água/rastro** opcional no material exibido, para atribuição. > Nota honesta: nenhum bloqueio é 100% contra um ator malicioso que ignore convenções; a força do > produto é **(a)** tornar a coleta tecnicamente inconveniente e **(b)** deixar **prova registrada** > de que o conteúdo estava marcado como reservado — o que sustenta ação contra uso indevido. ### 8.3 Liberação consentida (opt-in do autor) No painel, o autor **PODE** liberar uma obra (total ou parcialmente) para o público. A liberação: - É **explícita e granular** (por obra, e por campo: pode liberar título/resumo e manter o arquivo privado). - Exige **confirmação informada** de que o passo é **IRREVERSÍVEL** uma vez indexado externamente (uma vez que buscadores/IAs copiaram, não há como "despublicar" o que já foi coletado). - Gera um **evento de liberação registrado na ProtectChain** (com seu próprio timestamp e âncoras), provando *quando e o quê* o autor consentiu em abrir. ### 8.4 Publicação e indexação assistida (consentida) Quando o autor libera, a GlobalCopyrights **estimula** a difusão — agora **com consentimento**: - Gera uma **URL pública aberta** para a obra/verificação. - Produz automaticamente artefatos amigáveis a indexação **e a IAs**: **`.md`**, **JSON-LD** (schema.org `CreativeWork`), **`sitemap.xml`**, feed, e um **`llms.txt`** que — ao contrário do cofre — agora **permite** e descreve o conteúdo para consumo por IA. - Inverte os sinais anti-IA para *permitir* (remoção do `noai`, entrada no `tdmrep` como permitido, etc.). Ou seja, o **mesmo maquinário** que protege serve para promover — a chave é sempre o **consentimento do autor**, e o sistema deixa isso claro e auditável. ### 8.5 Irreversibilidade — registrada O ato de liberação **DEVE** ser precedido de aviso inequívoco e **DEVE** ser gravado na chain como evento imutável. Assim, fica provado que o conteúdo público foi **decisão consciente do autor** em data X — protegendo tanto o autor quanto a GlobalCopyrights. ## 8A. Dois eixos independentes: uso de IA na criação × proteção anti-coleta É **essencial** não confundir dois assuntos ortogonais. Tratá-los como um só levaria a excluir clientes legítimos. ### 8A.1 Eixo A — proteção contra coleta (crawlers de busca e de IA) É sobre **quem pode acessar/indexar** a obra depois de registrada. Controlado **exclusivamente pelo autor** (privado por padrão; liberação opt-in, §8.3–8.4). Aplica-se **independentemente** de como a obra foi criada. ### 8A.2 Eixo B — uso de IA como ferramenta na criação É sobre **como a obra foi feita**. Muitos autores usam IA como **ferramenta** (assistência, geração, edição). Isto **NÃO DEVE** ser impedimento ao registro — a ProtectChain registra **autoria e anterioridade declaradas**, **não** julga o processo criativo. - O autor **PODE** (opcional) preencher uma **declaração de uso de IA** — ex.: `none` / `assisted` / `ai-generated` / `mixed` — puramente como **transparência**. O sistema **NÃO DEVE** recusar, penalizar ou expor essa escolha sem consentimento. - Quando presente, essa declaração **PODE** ser propagada de forma padronizada via **C2PA** (§5A.4) para artefatos de mídia. ### 8A.3 Por que separar Um autor que gerou a obra **com** ajuda de IA **pode**, ainda assim, querer **proteger** essa obra contra coleta por outras IAs (Eixo A = reservado). E um autor que criou **sem** IA nenhuma **pode** querer **liberar** para indexação (Eixo A = liberado). As combinações são livres e ambas legítimas — os dois eixos são configurados **separadamente** pelo autor, sempre com ele no controle. ## 9. Fluxos **Registro de obra (privado):** autor sobe arquivo → gcorg cifra no Cofre e calcula sha256/sha512 → gcorg `POST /records` na ProtectChain (só hashes+metadados) → nó gera `record_hash` (pendente) → selagem periódica cria bloco assinado → âncoras FreeTSA (imediata) + OpenTimestamps (amadurece) → gcorg guarda `block_index`, `block_hash`, refs de âncora em `blockchain_records`. **Verificação (pública):** qualquer um faz `GET /verify/{cert|sha256}` → recebe registro, bloco, âncoras e resultado de checagem de cadeia/assinatura. Para provar um arquivo, recalcula-se o sha256 e compara-se com o registrado. **Liberação (consentida):** autor confirma no painel (aviso de irreversibilidade) → gcorg publica artefatos (URL, .md, JSON-LD, sitemap, llms.txt) e inverte sinais anti-IA → evento de liberação é registrado na ProtectChain. ## 10. Certificado e linguagem correta O certificado emitido **DEVE** declarar com precisão, sem prometer mais do que a lei permite: > *"Este certificado registra uma **autodeclaração de autoria**. A GlobalCopyrights atesta que, na > data **X** (UTC), o autor **Y** registrou em nossos sistemas e na **ProtectChain** uma obra cujo > conteúdo corresponde à impressão digital **SHA-256: …** (e SHA-512: …). O registro consta do bloco > **#N** da ProtectChain (hash …), com carimbo do tempo **RFC 3161** emitido por **[TSA]** em **T** e > ancoragem em **Bitcoin** via OpenTimestamps (prova …). A verificação independente está disponível > em **[URL]**. Este documento comprova a existência do conteúdo na referida data e a declaração de > autoria feita por Y; não constitui, por si, prova absoluta de originalidade."* ## 11. Considerações de segurança e privacidade - **Sigilo do conteúdo:** garantido por design (§7); nem a chain nem nós federados o veem. - **Chaves dos nós:** Ed25519, privadas locais, rotação registrada. - **Superfície de API:** submissão de registros exige **Bearer** por nó/cliente; verificação é pública e read-only. - **Disponibilidade:** três sítios + selagem idempotente; um nó fora não perde registros pendentes. - **Ameaça de retroação:** mitigada pelas âncoras externas — a chain não pode "reescrever o passado". - **LGPD:** metadados na chain **DEVEM** ser minimizados; `author_ref` opaco, sem PII na chain. ## 12. Considerações jurídicas A ProtectChain **produz meio de prova** (evidência de anterioridade + autodeclaração), não substitui registro oficial (ex.: US Copyright Office, WIPO, órgãos nacionais equivalentes). A comunicação ao usuário **DEVERIA** distinguir "proteção/registro na plataforma" de "registro público oficial". As âncoras (Bitcoin/TSA RFC 3161) aumentam substancialmente o peso probatório de forma **verificável em qualquer jurisdição** — que é o objetivo, já que o produto é **global**. Deliberadamente **não** nos amarramos a esquemas nacionais de presunção legal (ex.: ICP-Brasil): a força vem da tecnologia universal e da verificabilidade pública, aceitas internacionalmente. ## 13. Roadmap - **Fase 0 (atual):** nó único em dev (`pc-dev-dock`), selagem + âncoras + verificação; integração gcorg; texto do certificado. - **Fase 1:** 3 nós próprios (SP/CS/PI) em LXC dedicada; PoA multi-nó com co-assinatura; disciplina NTP (ntp.br/NIST); painel admin da chain. - **Fase 2:** Cofre de Conteúdo completo (bloqueio anti-crawler/IA + liberação consentida + artefatos de publicação). - **Fase 3:** Federação de terceiros com cadastro/autorização e **remuneração** (RFC ProtectChain-002); múltiplas TSAs internacionais; C2PA para mídia. ## Apêndice A — Endpoints do nó (fase 0) ``` GET /health identidade do nó + altura GET /chain?from=&to= lista de blocos GET /block/{id} bloco + registros + âncoras GET /verify/{cert|sha256|hash} prova de um registro POST /records (Bearer) submete registro (só hashes+metadados) POST /seal (Bearer) sela pendentes + ancora POST /anchor/upgrade (Bearer) amadurece provas OpenTimestamps ``` ## Apêndice B — Formas canônicas Ver §4.2. `record_hash` e `block_hash` são sha256 de strings canônicas com campos separados por `\n`; assinatura de bloco é Ed25519 sobre o `block_hash` em hexadecimal ASCII.