Vitalik Buterin usa pagamentos privados em ethereum por meio da ferramenta Kohaku-cli

O co-fundador do Ethereum, Vitalik Buterin, disse em um ensaio de 31 de outubro que o kohaku-cli gerenciou muitos dos pagamentos de Buterin envolvendo protocolos de privacidade. Buterin também afirmou que uma ferramenta de linha de comando escrita por IA realizou atualizações recentes nos hashes de conteúdo IPFS no ENS, o sistema de nomeação do Ethereum. O atualizador do ENS era uma aplicação diferente da carteira de pagamentos. Buterin se opõe a sites que fornecem código de aplicativo novamente em visitas subsequentes, o que torna os usuários repetidamente dependentes da entrega do servidor.

Um aplicativo retido localmente permite que o usuário mantenha uma revisão selecionada do software e decida quando instalar uma substituição. O código aceito atua como intermediário entre as instruções de pagamento e as assinaturas que autorizam pagamentos, de modo que dependências e acesso de assinatura permanecem relevantes. A documentação do Kohaku-cli descreve o aplicativo como não auditado, assistido por IA e em desenvolvimento ativo. A documentação aconselha os usuários a não utilizá-lo em mainnet, a menos que compreendam a atividade e o risco de perda catastrófica de fundos. O Kohaku-cli suporta contas públicas de Ethereum e saldos privados por meio do Tornado Cash, Railgun e Privacy Pools V1. A carteira é separada do conjunto mais amplo de bibliotecas de protocolo e infraestrutura de carteira do Kohaku, portanto, o aviso do aplicativo não constitui uma avaliação de auditoria de cada componente ou protocolo subjacente.

As instruções de instalação exigem que os usuários obtenham dependências com npm install, compilem a aplicação com npm run build e executem um launcher local. No commit 0ef5c44, a documentação, o manifesto, o arquivo de bloqueio e a implementação correspondem a uma revisão da aplicação. O manifesto especifica a versão 0.1.0 e o Node.js 22 ou posterior, mas Buterin não identificou a revisão instalada para uso de Buterin. O manifesto fixa as dependências diretas, incluindo viem e vários pacotes Kohaku, e fixa a dependência separada kohaku-artifacts do Git em um commit. O arquivo de bloqueio fornece pacotes resolvidos do registro e hashes de integridade, demonstrando que uma interface local ainda depende de uma cadeia de suprimentos de software. Aceitar uma substituição por meio desse processo de build local, portanto, envolve aceitar dependências e ferramentas de build, não apenas um nome de projeto familiar.

Para uma transferência pública comum sem agrupamento, a implementação simula a transação e produz resultados de execução de teste sem enviar a transação. A transmissão requer a chave privada do remetente e um cliente de carteira localmente construído, cuja conta de assinatura provém dessa chave. Um comando Railgun unshield pode, em vez disso, produzir um UserOperation preparado e já assinado sem transmitir a operação. Um UserOperation contém uma carga de operação de conta que ferramentas compatíveis podem enviar, e a implementação de transmissão separada envia uma operação assinada por meio de um bundler da Pimlico. Retardar o envio, portanto, nem sempre retém a assinatura, pois ferramentas compatíveis podem enviar posteriormente a operação assinada. A construção da autorização, a assinatura e o envio representam formas distintas de autoridade, mesmo quando uma única aplicação de linha de comando coordena as atividades.

Na implementação de transferência pública inspecionada, um chamador corretamente configurado com acesso à carteira pode combinar --non-interactive e --broadcast para enviar sem outra solicitação de confirmação. O desbloqueio da carteira, os parâmetros obrigatórios, a correspondência da cadeia e as verificações de simulação permanecem aplicáveis. Essa capacidade é relevante para scripts e agentes, mas não estabelece que Buterin realiza pagamentos não acompanhados. O README descreve o armazenamento em disco de um seed criptografado e arquivos de senha restritos ao proprietário para automação POSIX. Essas proteções controlam o armazenamento de segredos e o acesso ao processo, mas essas proteções sozinhas não impõem limites de gasto independentes ou regras de destinatário após um processo obter acesso ao assinante.

A proveniência de software registra a origem e o processo de construção de um artefato, fornecendo uma maneira de avaliar a entrega da aplicação. O padrão de verificação SLSA exige a validação da assinatura de proveniência e do digest do artefato, reconhecendo um construtor confiável e verificando se as fontes e parâmetros de construção correspondem às expectativas. Essas verificações podem ajudar a identificar artefatos substituídos ou fontes de construção inesperadas, mas sua eficácia depende dos construtores confiáveis e das expectativas de fonte do verificador. O SLSA trata a verificação recursiva das dependências resolvidas como um recurso opcional, portanto, autenticar o artefato principal não autentica automaticamente cada entrada de construção. Uma aplicação com registros válidos de origem e construção ainda pode conter comportamentos que o usuário rejeitaria.

A documentação da CLI especifica o uso padrão do Tor para algum tráfego não-RPC, enquanto o tráfego RPC do Ethereum utiliza a conexão de rede normal. Uma interface local, portanto, não torna todas as interações externas privadas. Manter o código da aplicação e controlar substituições oferece aos usuários uma forma concreta de controle, mas o benefício depende de estender esse controle às escolhas de dependências e à autoridade dos assinantes.