Resumo

  • Em draft-mih-scitt-checkpointed-local-log-01, um checkpoint e uma prova MMR confirmam que o ramo apresentado prolonga seu próprio predecessor, mas não que seja o único histórico criado pelo produtor.
  • A continuidade exige uma testemunha independente que retenha o último checkpoint aceito para a mesma identidade. Registro SCITT simples prova inclusão — e tempo somente quando assinado —, não ausência de bifurcação.

Imagine uma plataforma que assina cada decisão automatizada, mas guarda os recibos em armazenamento comum. No dia da auditoria, todas as assinaturas são válidas. Ainda assim, ninguém sabe se uma decisão inconveniente foi apagada antes de o conjunto ser apresentado.

O Checkpointed Local Log tenta preservar privacidade sem aceitar essa lacuna. O produtor adiciona resumos dos registros a uma Merkle Mountain Range. De tempos em tempos, assina um checkpoint pequeno que compromete o tamanho e o acumulador. Só esse compromisso precisa sair do domínio local.

O ganho é real. A conclusão confortável — “o checkpoint validou, então este é o histórico” — não é.

Consistência não significa exclusividade

O checkpoint contém o estado atual e o predecessor: log_size, commitment, prev_size e prev_commitment. Com a prova correspondente, um verificador confirma que o estado novo estende o anterior sem reescrever entradas já comprometidas naquele ramo.

Um produtor pode, porém, manter A e B. Cada ramo tem predecessores corretos e provas válidas. O auditor que recebe A não vê B; o auditor que recebe B não vê A. A matemática responde se a relação entregue é válida, não se outra relação foi escondida.

A testemunha consciente de checkpoints precisa recordar. Ela retém o último estado aceito para a identidade composta pelo emissor e pelo identificador do log. Na próxima submissão, compara o predecessor declarado com sua memória. Se houver diferença, deve rejeitar e registrar evidência de mutação. Tratar a divergência como erro temporário e repetir a operação apagaria o sinal de segurança.

Continuidade, portanto, não está em um carimbo isolado. Ela nasce da custódia de estado anterior por uma autoridade separada e da obrigação de dizer não.

Um Receipt pode provar menos do que seu rótulo sugere

O CLL reutiliza SCITT. Um checkpoint pode ser registrado como Signed Statement, recebendo um Receipt COSE. Esse Receipt atesta que o serviço incluiu o objeto sob sua chave. Só atesta o tempo se contiver uma alegação temporal assinada.

Um Transparency Service que desconheça CLL pode registrar o checkpoint normalmente. O resultado não ganha por isso a semântica de continuidade. Para tanto, o serviço precisa guardar o checkpoint anterior daquele log e realizar a comparação de predecessor antes de aceitar o seguinte.

Essa diferença precisa sobreviver ao marketing. “Registrado em transparência” informa inclusão. “Testemunhado com continuidade” informa que o serviço viu uma extensão de sua própria memória. Contratos, auditorias e APIs devem dizer qual operação ocorreu.

Uma testemunha de contrassinatura direta deve executar o mesmo teste. Já um stub local serve apenas a desenvolvimento. A revisão 01 move esse formato para trabalho futuro porque nenhuma implementação distribuída constrói a estrutura RFC 9338 antes imaginada. Um campo JSON privado não deve aparecer como evidência independente.

Réplica e testemunha ocupam lugares diferentes

O produtor deve nomear as testemunhas invocadas. Se ele mesmo opera uma delas, o rascunho a chama de réplica. A cópia pode ser útil para disponibilidade, mas continua sob a autoridade capaz de produzir os dois ramos.

Várias testemunhas independentes dificultam a equivocação porque o produtor precisa manter separada a visão de cada uma consultada. O efeito depende de independência administrativa e de consulta real. Quatro endpoints na mesma organização podem continuar sendo uma única superfície de autoridade.

Também existe um limite frontal. Entradas posteriores ao último checkpoint testemunhado são tão fortes quanto um log não testemunhado. O Receipt do turno anterior não cobre a cauda atual. A cadência máxima declarada torna uma ausência observável, mas a janela de retrodatação continua sendo a cadência mais a latência da testemunha.

A testemunha vê o desenho, não o conteúdo

O checkpoint compromete a forma do histórico. A testemunha pode ajudar a provar inclusão, ordem e completude de um intervalo sob aquele compromisso. Ela não recebe os registros e não funciona como índice independente. Para verificar uma decisão individual, alguém ainda precisa apresentar seus bytes e a prova de inclusão.

Se um segmento arquivado não puder mais ser lido, o checkpoint pode mostrar que uma entrada existiu, mas não recriá-la. A resposta correta é “retenção expirada”, não “nunca existiu”.

Nem um histórico perfeitamente testemunhado transforma afirmações falsas em fatos. Autorização, execução e efeito exigem confirmação externa. O CLL tampouco prova que aquele é o único log do produtor ou que toda decisão produzida foi anexada. Ele limita omissões dentro de um histórico comprometido.

A revisão 01 esclarece a forma na rede. commitment e prev_commitment carregam a lista de picos MMR em CBOR canônico. Uma raiz agregada pode existir internamente, mas seu algoritmo de dobra não é padronizado e não deve ser transmitido. Isso define uma proposta verificável; não prova interoperabilidade ou adoção. O documento continua sendo uma submissão individual sem posição formal no processo IETF.

Fontes