Protocolo de Compromisso de Observação (OCP) v1.0.0 – Criptografia

Atualização: Envelope de Prova, Implementação de Referência EVM e Direção Cross-Chain

Desde o post original e o desafio adversário, o OCP passou de um protótipo de cadeia única para um primitivo de cadeia cruzada. Esta postagem resume o que foi construído, o que está bloqueado e para onde o protocolo está indo.

O problema que esta atualização resolve

A postagem original deixou a regra de extração R definido pela implementação – correto para uma especificação mínima, mas insuficiente para um verificador portátil. Duas implementações que usam regras de extração diferentes podem reivindicar conformidade com as especificações e serem mutuamente incompatíveis. Desde então, o trabalho tem sido preencher essa lacuna sem comprometer a estreiteza do primitivo.

O que foi construído

Esquema de envelope de prova v1.0.0

A estrutura de prova P = (observation, H, tx_ref) agora é formalizado como um artefato JSON autodescritivo e independente de cadeia. A restrição crítica do projeto:

Um envelope de prova OCP válido deve ser verificável em relação aos dados contábeis brutos — sem SDK, sem provedor de RPC, sem necessidade de indexador.

Campos principais:

• chain.id — Identificador da cadeia CAIP-2 (eip155:1, eip155:84532etc.)
• chain.namespace — família de arquitetura de razão (evm, solana, cosmos, bitcoin)
• commitment.serialization – explícito (raw-bytes somente na v1.0) — elimina falhas de verificação silenciosas causadas por incompatibilidades de codificação
• ledger_ref — ID da transação, altura do bloco, hash do bloco, profundidade de finalidade
• extraction.rule_id — identificador de regra com namespace (evm/event-log, solana/instruction-data)

Especificações: docs/spec/ocp-proof-envelope-v1.0.0.md

Regra de extração EVM: evm/event-log

R agora é formalmente especificado para cadeias EVM em relação à estrutura de recebimento decodificada por RLP bruta – não às chamadas de SDK:

R(receipt) = { topic(1) : log ∈ receipt.logs,
                           log.topics(0) = keccak256("Recorded(bytes32,address)"),
                           len(log.topics) >= 2 }

Contrato de referência implantado na Base Sepolia 0x0963Fd33DF80c94360F2DC22e5c09517AeE7ED5c:

contract ObservationCommitment {
    event Recorded(bytes32 indexed digest, address indexed recorder);
    function record(bytes32 digest) external {
        emit Recorded(digest, msg.sender);
    }
}

Especificações: docs/spec/appendix-evm-r.md

Verificador de referência de dependência zero

O verificador de referência realiza verificação ao vivo na cadeia usando apenas Node.js stdlib – sem ethers.js, sem web3, sem axios. Chamada HTTPS JSON-RPC bruta para eth_getTransactionReceiptanálise de tópico de log, confirmação de resumo.

Saída ao vivo em relação a uma transação real da Base Sepolia:

  hash      MATCH  14cca453684a18c1ef3e1c0b9a7744cfa06942660719bba373ef5fc36208bf73
  chain     eip155:84532
  rpc       https://sepolia.base.org
  tx        0xf2e1f6c085768b4e3d60463717d52bb2a338803a74a4cfd48aea5738d2595ddd
  logs      found 1 Recorded event(s)
  digest    MATCH  14cca453684a18c1ef3e1c0b9a7744cfa06942660719bba373ef5fc36208bf73

VALID

Isto encerra o desafio original da falsificação: o procedimento de verificação agora é explícito o suficiente para que qualquer pessoa possa implementar um verificador apenas a partir da especificação, sem dependência de qualquer ferramenta ou provedor nomeado.

Coordenação entre cadeias – o que está bloqueado

OCP foi referenciado no tópico ERC-8004 (Universal AI Inference Verification Registry) no Ethereum Magicians. A arquitetura que converge para lá é mapeada diretamente para o OCP como uma primitiva:

trust layer       →  inputSources + sanitize()
provenance layer  →  verifyInputProvenance()
OCP primitive     →  digest → commitment → verify inclusion
proof layer       →  verify(modelHash, inputHash, outputHash, proof)
registry          →  coordinates interoperability

OCP fica na camada 3. Seu limite permanece estreito – ele não afeta a semântica de sanitização, especificações de pipeline ou política de procedência. No momento em que o OCP padroniza essas preocupações ele deixa de ser um primitivo e passa a ser uma aplicação.

Através dessa coordenação, foi confirmado o seguinte entre duas implementações independentes:

Hash sentinela do pipeline de identidade — um hash fixo canônico para o caso “sem higienização”, confirmado independentemente por duas implementações usando chave classificada SHA-256:

spec:  {"controlCharExclusions":null,"controlCharRanges":null,"maxLength":null,
        "patternFlags":null,"patterns":(),"provenanceLabel":null,
        "replacementToken":null,"sourceType":"identity",
        "specVersion":"erc-8004-security/identity","transformation":"none"}

hash:  8116eec29078e8f57c07077d5e8080a35bde73036581df3abb93755d1b1a16ea

Duas implementações independentes, mesmo resultado. É assim que os padrões são feitos.

Conexão com o estudo de caso de composição síncrona

O estudo de caso da postagem anterior identificou uma lacuna: a composição síncrona resolve como executar atomicamente entre domínios, mas deixa em aberto qual é o objeto canônico que representa o resultado dessa execução.

O envelope de prova torna isso concreto. Uma raiz de tabela de execução confirmada via OCP produz um artefato de prova portátil e autodescritivo que:

• identifica em qual cadeia o compromisso foi assumido
• especifica exatamente como extrair o resumo da transação bruta
• registra a profundidade da finalidade no momento do compromisso
• é verificável a partir de dados brutos de bloco sem dependência de infraestrutura

O padrão do estudo de caso é válido:

execution → proof → commitment

O envelope é o que a camada de compromisso produz. É a referência portátil.

O que vem a seguir

A Fase 3 é o apêndice Solana – definindo R para o modelo de conta/instrução. A estrutura de transação de Solana é fundamentalmente diferente da EVM: sem logs, sem tópicos, dados de instrução em vez de dados de chamada, semântica de finalidade diferente. Se o formato do envelope de prova for mantido sem modificação no EVM e no Solana, a abstração será genuinamente independente da cadeia. Se precisar de alterações, a costura ficará visível e as especificações poderão ser atualizadas antes que o design seja bloqueado.

Esse teste é a diferença entre um protocolo que afirma ser agnóstico em cadeia e outro que o prova.

Repositório: GitHub – damonzwicker/observation-commitment-protocol: Um protocolo mínimo para verificar de forma independente se uma sequência de bytes específica foi confirmada em um livro-razão público. · Github