Vitalik Buterin utilise des paiements privés sur ethereum via l'outil Kohaku-cli

Le cofondateur d'Ethereum, Vitalik Buterin, a déclaré dans un essai du 31 octobre que kohaku-cli a géré de nombreux paiements de Buterin impliquant des protocoles de confidentialité. Buterin a également indiqué qu'un outil en ligne de commande écrit par une IA a géré les récentes mises à jour des hachages de contenu IPFS sur ENS, le système de nommage d'Ethereum. L'outil de mise à jour ENS était une application différente du wallet de paiement. Buterin s'oppose à ce que les sites web fournissent à nouveau le code de l'application lors des visites ultérieures, ce qui rend les utilisateurs dépendants à chaque fois de la livraison du serveur.

Une application conservée localement permet à l'utilisateur de conserver une révision logicielle sélectionnée et de décider quand installer une mise à jour. Le code accepté sert d'intermédiaire entre les instructions de paiement et les signatures autorisant les paiements, de sorte que les dépendances et l'accès à la signature restent cruciales. La documentation de Kohaku-cli décrit l'application comme non auditée, assistée par l'IA et en développement actif. La documentation conseille aux utilisateurs de ne pas l'utiliser sur le mainnet à moins qu'ils ne comprennent l'activité et le risque de perte catastrophique de fonds. Kohaku-cli prend en charge les comptes publics Ethereum et les soldes privés via Tornado Cash, Railgun et Privacy Pools V1. Le wallet est séparé du kit plus large Kohaku composé de bibliothèques de protocoles et d'infrastructure de wallet ; par conséquent, l'avertissement de l'application ne constitue pas une évaluation d'audit de chaque composant ou protocole sous-jacent.

Les instructions d'installation exigent que les utilisateurs récupèrent les dépendances avec npm install, compilent l'application avec npm run build et exécutent un lanceur local. Au commit 0ef5c44, la documentation, le manifeste, le fichier de verrouillage et l'implémentation correspondent à une révision unique de l'application. Le manifeste spécifie la version 0.1.0 et Node.js 22 ou ultérieure, mais Buterin n'a pas identifié la révision installée pour son utilisation. Le manifeste verrouille les dépendances directes, notamment viem et plusieurs paquets Kohaku, et fixe la dépendance Git séparée kohaku-artifacts à un commit. Le fichier de verrouillage fournit les paquets résolus du registre et leurs hachages d'intégrité, démontrant qu'une interface locale dépend toujours d'une chaîne d'approvisionnement logicielle. Accepter un remplacement via ce processus de construction locale implique donc d'accepter les dépendances et les outils de construction, et non simplement un nom de projet familier.

Pour un transfert public ordinaire sans regroupement, l'implémentation simule la transaction et produit des résultats en mode dry-run sans soumettre la transaction. La diffusion nécessite la clé privée de l'expéditeur et un client wallet construit localement dont le compte de signature provient de cette clé. Une commande Railgun unshield peut au contraire produire un UserOperation préparé et déjà signé sans diffuser l'opération. Un UserOperation contient une charge utile d'opération de compte que des outils compatibles peuvent soumettre, et l'implémentation de diffusion séparée envoie l'opération signée via un bundler Pimlico. Le fait de retenir la soumission ne retient donc pas toujours la signature, car des outils compatibles pourraient ultérieurement soumettre l'opération signée. La construction de l'autorisation, la signature et la soumission représentent des formes distinctes d'autorité, même si une seule application en ligne de commande coordonne ces activités.

Dans l’implémentation publique de transfert examinée, un appelant correctement configuré avec un accès au wallet peut combiner les options --non-interactive et --broadcast pour soumettre la transaction sans autre invite de confirmation. Le déverrouillage du wallet, les paramètres obligatoires, la correspondance de la chaîne et les vérifications de simulation restent applicables. Cette fonctionnalité est importante pour les scripts et les agents, mais ne signifie pas que Buterin effectue des paiements non supervisés. Le README décrit un stockage sur disque d’un seed chiffré et de fichiers de mot de passe restreints au propriétaire pour une automatisation POSIX. Ces protections contrôlent le stockage des secrets et l’accès au processus, mais ces protections seules n’imposent pas de limites de dépense indépendantes ou de règles de destinataire après qu’un processus a obtenu l’accès au signataire.

La provenance logicielle enregistre l'origine et le processus de construction d'un artefact, offrant un moyen d'évaluer la livraison de l'application. La norme de vérification SLSA exige la validation de la signature de provenance et du condensé de l'artefact, la reconnaissance d'un constructeur de confiance, ainsi que la vérification des paramètres source et de construction par rapport aux attentes. Ces contrôles peuvent aider à identifier des artefacts substitués ou des sources de construction inattendues, mais leur efficacité dépend des constructeurs de confiance et des attentes en matière de source du vérificateur. SLSA considère la vérification récursive des dépendances résolues comme un complément facultatif, de sorte que l'authentification de l'artefact principal n'authentifie pas automatiquement chaque entrée de construction. Une application avec des enregistrements d'origine et de construction valides peut encore contenir des comportements que l'utilisateur rejeterait.

La documentation CLI spécifie une utilisation par défaut de Tor pour certains trafics non-RPC, tandis que le trafic RPC Ethereum utilise la connexion réseau normale. Une interface locale ne rend donc pas toutes les interactions externes privées. Conserver le code de l'application et contrôler les remplacements offre aux utilisateurs une forme concrète de contrôle, mais le bénéfice dépend de l'étendue de ce contrôle aux choix de dépendances et à l'autorité des signataires.