As provas do CardanoWall funcionam offline?

Sim — para tudo o que já está no seu dispositivo. Depois que um registro Label 309, seu conteúdo ou texto cifrado, e as chaves para abri-lo estão sincronizados, o CardanoWall Desktop consegue navegar, pesquisar, decifrar e verificá-los sem nenhuma conexão de rede. O que ele não consegue é inventar dados que nunca viu: uma transação que nunca sincronizou, ou um texto cifrado que nunca baixou.

O CardanoWall Desktop foi pensado para o offline em primeiro lugar. Seu banco de dados local é a fonte de verdade para a tela à sua frente; a rede é um sincronizador em segundo plano que preenche esse banco de dados. Então "offline" é um modo normal, não um erro — a máquina local se torna uma cópia de trabalho da parte do mundo das provas que você já baixou.

Essa cópia de trabalho é exatamente o que torna as provas úteis em campo: durante uma viagem, uma auditoria, uma revisão jurídica, uma resposta a incidentes, ou em qualquer lugar onde a conexão é instável. Uma prova não deveria ficar ilegível só porque uma aba não consegue alcançar um servidor. O CardanoWall Desktop é de código aberto — construído em Rust com Tauri sobre o SDK Rust de código aberto, com seu código em github.com/cardanowall — então você pode ler exatamente como ele se comporta em vez de aceitar isso por fé.

O que você consegue fazer offline com provas sincronizadas?

Muita coisa, desde que os dados já estejam locais. Se estiverem, o CardanoWall Desktop permite que você:

navegue pelos registros públicos Label 309 sincronizados;
pesquise no espelho local de registros, inclusive por hash do conteúdo;
veja os registros da Inbox já descobertos por decifração por tentativa;
abra o texto cifrado em cache;
decifre arquivos selados com suas chaves locais;
verifique hashes contra arquivos locais;
confira a estrutura dos registros em cache;
revise o histórico dos seus registros enviados;
prepare rascunhos para publicar depois.

São operações criptográficas de verdade, não capturas de tela em cache. A verificação do hash, a verificação da assinatura, a decifração por tentativa — todas elas rodam localmente no núcleo Rust do app, contra bytes que já estão no disco.

O que você não consegue fazer offline?

O modo offline tem um limite bem definido, e ele é honesto sobre onde esse limite está. O app não consegue fabricar dados que nunca teve.

Se uma transação nunca foi sincronizada, o app não tem como saber que ela existe sem a rede ou alguma outra cópia local dos metadados dela.
Se um texto cifrado nunca foi baixado, o app não consegue decifrá-lo offline.
Se um registro aponta para uma URI de armazenamento e esses bytes não foram armazenados em cache, o app não consegue buscá-los sem uma conexão.
Se você quer publicar uma nova prova, o app precisa de um gateway e de uma rede: ele tem de cotar a publicação, fazer o upload, submeter a transação Cardano e confirmá-la. (A publicação sempre passa por um gateway — veja por que publicar tem um preço.)

Priorizar o offline não é afirmar que o app consegue preencher dados que faltam. É afirmar que, uma vez que os dados estão locais, o app os trata como cidadãos de primeira classe.

O que o app armazena em cache, e quão sensível é cada camada?

São quatro camadas, em ordem crescente de sensibilidade.

Metadados de registros públicos. O desktop mantém um espelho local completo dos registros Label 309 — selados e públicos — do gateway que você configurou. Cada registro é pequeno (os metadados de uma única transação, com um limite bem abaixo do teto de metadados de cerca de 16 KB do Cardano), de modo que o conjunto global inteiro fica na faixa de algumas centenas de megabytes, mesmo após anos de uso intenso. Esse espelho é o substrato para a pesquisa, a descoberta da Inbox, o rastreamento de registros enviados e a inspeção offline. Ele contém apenas o que já é público na cadeia, então é armazenado sem criptografia por design — cifrar uma cópia de dados públicos não traz nenhum ganho.

Texto cifrado. Os registros selados referenciam cargas úteis cifradas por meio de armazenamento endereçado por conteúdo (ar:// ou ipfs://). Armazenar esse texto cifrado em cache é seguro porque ele já está cifrado; só pode ser aberto por alguém que detenha uma chave correspondente. O desktop o mantém em cache para que reabrir um arquivo recebido seja instantâneo e funcione offline.

Conteúdo decifrado. Esta é a camada sensível, e o app a trata com cuidado. Por padrão, ele decifra sob demanda na memória e nunca grava texto claro no disco. Existe um cache opcional, cifrado separadamente, de arquivos decifrados, para usuários que querem prévias instantâneas sem precisar reabrir o selo, mas ele vem desligado por padrão, e o texto claro só é gravado em um local comum quando você escolhe Salvar explicitamente. Você deve sempre saber quando os arquivos decifrados são mantidos, onde, e como são protegidos.

Material de identidade. As Identity Seeds vivem em um cofre cifrado e são desbloqueadas localmente. Sem a identidade relevante desbloqueada, um registro selado ainda pode aparecer no espelho como um registro público — você simplesmente não consegue abrir o conteúdo dele. A própria semente nunca sai do dispositivo e nunca chega a nenhum gateway. (Para entender por que esse limite importa, veja por que as chaves nunca saem do dispositivo.)

Você consegue verificar uma prova offline?

Sim — uma vez que você tenha as entradas de que a verificação precisa. A verificação Label 309 foi projetada para rodar apenas a partir de dados públicos, então as checagens criptográficas não têm dependência dos servidores do CardanoWall. O que cada verificação precisa:

Uma prova de hash precisa do registro e dos bytes originais. O verificador recalcula o hash a partir dos bytes e o compara ao hash fixado no registro. Totalmente offline.
Uma prova assinada precisa do registro e de sua assinatura embutida. A chave de assinatura é carregada na estrutura de assinatura do registro ou resolvida a partir dela, então a verificação da assinatura roda offline assim que o registro está local.
Uma prova selada precisa do registro, do texto cifrado, e da chave do destinatário (ou senha) que o abre. Com isso local, o app decifra, recalcula o hash do texto claro, e o confere contra o compromisso do registro — o passo que liga os bytes cifrados de volta à afirmação carimbada no tempo.
Uma prova Merkle precisa da raiz do registro mais a prova de inclusão (ou a lista de folhas para reconstruí-la). Então a verificação de inclusão roda offline, sem nenhum gateway no circuito. Construir uma árvore Merkle e verificar a inclusão são computação pura — veja um registro para milhares de arquivos.

A única coisa que normalmente precisa da rede é obter dados que você ainda não tem, além de confirmar o estado atual da cadeia. A matemática em si roda localmente. (Para o modelo completo de verificação, veja como verificar um registro Label 309.)

E quanto à confirmação na blockchain quando você está offline?

O carimbo de tempo de uma prova e seu status de confirmação vêm do Cardano, e esses são fatos que o app lê da cadeia — ele nunca os inventa.

Se o app já sincronizou uma transação e sua profundidade de confirmação, ele consegue mostrar esse estado em cache offline. O que ele não consegue fazer offline é tomar conhecimento de novas confirmações, de uma reorganização da cadeia, ou de qualquer contexto atualizado, porque isso exige consultar um explorador Cardano.

Então um cliente cuidadoso mantém estes estados distintos:

dados de registro em cache, verificados localmente;
a última vez que cada item foi sincronizado;
a profundidade de confirmação na época da última sincronização;
registros ainda pendentes ou abaixo do limiar de confirmação;
registros que precisam de uma nova reverificação online.

A exibição offline deve ser honesta quanto à atualidade. Ela nunca deve apresentar a profundidade de confirmação da semana passada como se fosse a atual.

Como funciona a descoberta da Inbox offline?

Sua Inbox é computada localmente a partir de duas coisas: o espelho de registros e suas identidades desbloqueadas. O gateway é deliberadamente cego ao destinatário — ele não faz ideia de quais registros selados são "seus" — então encontrar sua correspondência é, por design, um trabalho local.

Se o app sincronizou registros selados, ele os decifra por tentativa contra suas identidades ali mesmo no dispositivo. Para cada compartimento selado, ele tenta uma decifração; aqueles que suas chaves conseguem abrir são suas mensagens. Nenhum servidor é consultado sobre quem você é.

É também por isso que importar uma Identity Seed antiga funciona perfeitamente offline. Como só a chave do destinatário decide uma correspondência, o app reexamina o espelho local já presente em busca daquela identidade e revela registros selados mais antigos que haviam sido endereçados a ela — uma passagem local, sem novo download. (Sua identidade é exatamente essa semente; veja sua identidade é uma semente.)

Se o espelho estiver incompleto, a Inbox pode ficar incompleta. Quando a rede volta, o app sincroniza os registros que faltam e continua a descoberta.

Por que não manter tudo apenas na nuvem?

Porque a nuvem não deveria ser a raiz da confiança. Um serviço hospedado é conveniente — ele pode publicar registros, servir o feed, cuidar da precificação, e tornar a interface fácil. Mas uma prova deveria sobreviver a qualquer conta de serviço isolada, e todo o objetivo do Label 309 é que a verificação precise apenas de infraestrutura pública: os metadados da transação, opcionalmente os bytes do conteúdo, e um explorador Cardano público. Uma cópia de trabalho local dos registros com que você se importa é a expressão prática dessa independência.

Essa cópia local se justifica exatamente nas situações em que uma única sessão web é frágil demais: auditorias, resposta a incidentes, retenções legais, revisão de provas, jornalismo, arquivos de pesquisa, fluxos de trabalho regulados, e preservação de longo prazo.

Como uma equipe deveria usar provas offline?

Decida, com antecedência, o que você pode precisar provar sem uma rede — e então sincronize e armazene em cache o material de verificação antes que a rede desapareça.

O formato de "o que armazenar em cache" segue o trabalho:

Uma equipe jurídica pode querer pacotes de provas cifradas em cache em uma máquina aprovada.
Uma equipe de conformidade pode querer os registros de prova e as provas de inclusão de cada dia disponíveis durante uma auditoria.
Uma equipe de lançamento ou DevSecOps pode querer provas de build e manifestos de lançamento em cache junto com o arquivo de lançamento.
Uma equipe de IA pode querer manifestos de conjuntos de dados e compromissos de saída de modelo espelhados localmente.

A regra é simples: se você pode precisar prová-lo offline, sincronize-o e armazene em cache o material que o prova antes que a conexão desapareça. Para conteúdo selado, confirme também que a Identity Seed relevante tem backup e está disponível para as pessoas ou dispositivos certos, conforme a sua política — sem ela, o texto cifrado permanece fechado.

Quais são os riscos de manter provas localmente?

O acesso offline transfere parte da responsabilidade para o dispositivo, e vale a pena ser claro sobre isso.

Há o risco de armazenamento local. Se um dispositivo é roubado, seus caches importam. O texto cifrado em cache está cifrado e não pode ser aberto sem uma chave, mas quaisquer arquivos decifrados que você escolheu manter são sensíveis, e o cofre de identidade precisa ser protegido. O sistema operacional, a criptografia de disco, a conta de usuário, a senha, e a segurança geral do dispositivo passam todos a fazer parte do modelo de confiança. O CardanoWall Desktop reduz a exposição com um cofre cifrado, bloqueio automático, e zeroização das chaves na memória na medida do possível, mas não consegue defender uma máquina totalmente comprometida e desbloqueada — e diz isso com franqueza.

Há também o risco de atualidade. Uma prova em cache é válida na época de sua última sincronização, mas o app não tem como saber o estado atual da cadeia até reconectar.

Um bom software torna esses limites visíveis: mostra o horário da última sincronização, distingue uma verificação em cache de uma verificação online recente, e evita gravar silenciosamente texto claro decifrado em locais inseguros.

O que você deve guardar para uma prova de longo prazo?

Para provas que importam por anos, guarde mais do que o hash da transação. Dependendo do tipo de prova, isso significa:

a referência da transação;
os bytes do registro Label 309 (ou uma exportação verificada);
o arquivo original ou o texto claro;
o texto cifrado, no caso de registros selados;
a Identity Seed ou o segredo do destinatário necessário para decifrar;
a lista de folhas Merkle ou as provas de inclusão;
quaisquer assinaturas ou chaves públicas necessárias para a atribuição;
uma breve nota sobre como a prova foi criada e a que processo ela pertence.

A blockchain fornece a âncora pública — o fato de que estes bytes exatos já existiam em um tempo de bloco público. Seu arquivo local preserva o contexto que torna a âncora útil depois. (E lembre-se do que a âncora afirma e do que não afirma: veja o que uma prova não prova.)

A versão curta

A prova offline não é mágica; é preparação. Se o registro, o conteúdo, o texto cifrado, as chaves, e quaisquer provas de inclusão estão locais, todas as checagens criptográficas rodam localmente. Se algo nunca foi sincronizado ou armazenado em cache, o app precisa da rede para buscá-lo — e te avisa disso em vez de fingir.

O CardanoWall Desktop torna essa cópia de trabalho local algo normal: ele sincroniza os registros, descobre os itens selados da Inbox no dispositivo, mantém arquivos cifrados em cache, verifica provas, e mantém úteis as provas já sincronizadas mesmo quando a rede desaparece.

Leitura adicional

CardanoWall Desktop — o cliente desktop de código aberto que este artigo descreve.
Como verificar um registro Label 309 — o modelo de verificação por completo.
Um registro para milhares de arquivos — agrupamento Merkle, tudo offline exceto a publicação.
O que uma prova não prova — os limites de uma prova de existência carimbada no tempo.
O código de código aberto, a CLI e os SDKs: github.com/cardanowall.