Helius leva privacidade à Solana com confiança operacional

•

A Helius lançou, em 10 de novembro, a Privacy Ring na rede principal da Solana. Com isso, o sistema permite ocultar os tipos e os valores envolvidos em pagamentos. Entretanto, os endereços das carteiras do remetente e do destinatário continuam visíveis.

Na configuração padrão, um provador remoto cria as provas de conhecimento zero. Nesse processo, um enclave AWS Nitro atestado recebe e processa os dados sigilosos da transação. Dessa forma, a Solana verifica as regras do protocolo, mas a confidencialidade depende do isolamento e da implantação do provador.

Para desenvolvedores de carteiras, a questão central envolve as proteções que o software consegue verificar. Embora a prova confirme que a transferência segue as regras, ela não garante a confidencialidade da máquina responsável por sua geração. Ainda assim, a atestação permite conferir se o ambiente corresponde a uma política previamente aprovada.

Como a rede processa as provas privadas

O guia de integração para carteiras da Helius informa que a geração da prova exige entradas em texto simples. Essas entradas incluem os dados completos da transação e as chaves de nullifier. Ao mesmo tempo, o documento identifica um enclave AWS Nitro atestado como provador padrão dos SDKs.

A especificação do protocolo lista tipo, valor, fatores de blindagem e segredo do nullifier entre as entradas privadas. Além disso, ela inclui os caminhos que demonstram a presença das notas na árvore de estado. A prova também contém tipos, valores e dados de blindagem das saídas.

O código do provador lê essas informações dentro do enclave. Por isso, o cliente documentado criptografa as solicitações com uma chave mantida pelo ambiente atestado. Dessa maneira, o operador do host não deveria conseguir acessar diretamente os dados enviados.



Os dados sigilosos seguem para o enclave, mas a chave de assinatura permanece na carteira.
O fluxo padrão envia entradas criptografadas ao AWS Nitro, recebe a prova e somente depois assina a transação na Solana.

 

Assinatura e visualização cumprem funções distintas

O segredo do nullifier gera marcadores que impedem gastos repetidos. Contudo, esse segredo não substitui a assinatura do proprietário. Na integração nativa, a carteira mantém a chave, enquanto o SDK TypeScript deixa a assinatura final sob controle da aplicação.

A Helius documenta opções de decriptação local e delegada. No modelo local, a chave de visualização permanece no dispositivo do usuário. Em contrapartida, a delegação compartilha essa chave com um provedor autorizado, que obtém acesso a saldos e histórico, mas não pode gastar os recursos.

A AWS descreve os Nitro Enclaves como ambientes isolados. Assim, processos e administradores da instância principal não conseguem acessar a memória do enclave. Esses ambientes também não possuem armazenamento persistente, acesso interativo ou conexão externa de rede.

Confiança permanece ligada à implantação

O documento assinado pela AWS contém impressões criptográficas da imagem e do software. Primeiro, as verificações analisam a cadeia de certificados, a resposta ao desafio, a atualização e as medições aprovadas. Depois, o processo confere o vínculo da chave de criptografia.

Antes de enviar a solicitação remota, o SDK versionado rejeita pedidos sem uma política configurada. A carteira pode fixar uma política de lançamento revisada ou adotar uma política de rede autenticada pelos signatários definidos no SDK. Enquanto isso, os signatários atualizam as políticas durante a atestação, e cada política expira após o uso.

Contudo, a escolha da imagem aprovada ainda exige confiança no código e em seus revisores. O guia de implantação do Nitro afirma que a imagem medida inclui o provador, o script de inicialização e os certificados. Ela também incorpora os hosts autorizados, a URL do indexador e a identidade da chave KMS.

Metadados ampliam as dependências do operador

A arquitetura utiliza o AWS KMS para liberar uma semente criptografada compartilhada. Na prática, apenas enclaves que correspondem à atestação recebem essa semente. Porém, o cliente precisa confiar na associação inicial entre a política e o ambiente implantado.

Segundo o guia, os clientes não conseguem ler a política da chave KMS. Logo, eles dependem da configuração realizada pelo operador para obter essa garantia. O documento identifica AWS KMS, AWS Support, hardware Nitro e o operador como raízes de confiança nessa associação inicial.

Mesmo solicitações criptografadas deixam alguns metadados visíveis ao ambiente principal. Entre eles estão caminhos, consultas, horários e tamanhos das requisições. Inclusive, o caminho utilizado pode revelar o formato do circuito responsável pela prova.

O guia versionado do ambiente confiável registra uma compilação para a rede principal baseada em v0.6.0-alpha. Por outro lado, essa versão difere da referência documental ts-sdk-v0.8.0-alpha. A especificação também permite provas no dispositivo do usuário, enquanto o repositório oferece ferramentas para rede local e binários do provador.

O anúncio da Helius afirma que Certora, zkSecurity e OtterSec auditaram programas e circuitos. Contudo, a página de segurança lista Certora em outubro e zkSecurity em agosto. Já o relatório da OtterSec aparece como aguardando publicação, o que deixa aos desenvolvedores a escolha do código e da política de implantação.

Google Notícias

Receba nossas últimas notícias em primeira mão.   Adicione-nos como sua fonte preferida no Google    e toque em “Favorito” para priorizar nossas atualizações.