Vitalik Buterin utiliza pagos privados de ethereum mediante la herramienta Kohaku-cli

El cofundador de Ethereum, Vitalik Buterin, dijo en un ensayo del 31 de octubre que kohaku-cli gestionó muchos de los pagos de Buterin relacionados con protocolos de privacidad. Buterin también dijo que una herramienta de línea de comandos escrita por IA gestionó actualizaciones recientes a los hashes de contenido IPFS en ENS, el sistema de nomenclatura de Ethereum. El actualizador de ENS era una aplicación diferente del monedero de pagos. Buterin se opone a que los sitios web suministren código de aplicación nuevamente en visitas posteriores, lo que hace que los usuarios dependan repetidamente de la entrega del servidor.

Una aplicación retenida localmente permite al usuario mantener una revisión seleccionada del software y decidir cuándo instalar una sustitución. El código aceptado actúa como intermediario entre las instrucciones de pago y las firmas que autorizan los pagos, por lo que las dependencias y el acceso a la firma siguen siendo cruciales. La documentación de Kohaku-cli describe la aplicación como no auditada, asistida por IA y en desarrollo activo. La documentación aconseja a los usuarios evitar su uso en mainnet a menos que comprendan la actividad y el riesgo de pérdida catastrófica de fondos. Kohaku-cli admite cuentas públicas de Ethereum y saldos privados a través de Tornado Cash, Railgun y Privacy Pools V1. El monedero es independiente del conjunto más amplio de bibliotecas de protocolo e infraestructura de monedero de Kohaku, por lo que la advertencia de la aplicación no constituye una evaluación de auditoría de cada componente o protocolo subyacente.

Las instrucciones de instalación requieren que los usuarios obtengan las dependencias con npm install, compilen la aplicación con npm run build y ejecuten un lanzador local. En el commit 0ef5c44, la documentación, el manifiesto, el archivo de bloqueo y la implementación corresponden a una revisión de la aplicación. El manifiesto especifica la versión 0.1.0 y Node.js 22 o posterior, pero Buterin no identificó la revisión instalada para su uso. El manifiesto fija las dependencias directas, incluyendo viem y varios paquetes de Kohaku, y fija la dependencia separada de Git kohaku-artifacts a un commit. El archivo de bloqueo proporciona paquetes resueltos del registro y hashes de integridad, demostrando que una interfaz local aún depende de una cadena de suministro de software. Aceptar una sustitución a través de este proceso de compilación local implica aceptar dependencias y herramientas de compilación, no solo un nombre de proyecto familiar.

Para una transferencia pública ordinaria sin agrupación, la implementación simula la transacción y produce resultados de ejecución de prueba sin enviar la transacción. La transmisión requiere la clave privada del remitente y un cliente de monedero construido localmente cuya cuenta de firma proviene de esa clave. Un comando Railgun unshield puede producir en cambio una UserOperation preparada y ya firmada sin transmitir la operación. Una UserOperation contiene una carga útil de operación de cuenta que las herramientas compatibles pueden enviar, y la implementación de transmisión separada envía una operación firmada a través de un bundler de Pimlico. Por lo tanto, retrasar la entrega no siempre implica retrasar la firma, ya que las herramientas compatibles podrían enviar posteriormente la operación firmada. La construcción de autorización, la firma y la entrega representan formas distintas de autoridad, incluso cuando una sola aplicación de línea de comandos coordina las actividades.

En la implementación de transferencia pública inspeccionada, un llamador correctamente configurado con acceso al monedero puede combinar --non-interactive y --broadcast para enviar sin otra solicitud de confirmación. El desbloqueo del monedero, los parámetros obligatorios, la coincidencia de la cadena y las verificaciones de simulación siguen siendo aplicables. Esta capacidad es relevante para scripts y agentes, pero no establece que Buterin realice pagos sin supervisión. El README describe el almacenamiento en disco de una semilla cifrada y archivos de contraseña restringidos al propietario para automatización POSIX. Esas protecciones controlan el almacenamiento de secretos y el acceso al proceso, pero estas protecciones por sí solas no imponen límites de gasto independientes ni reglas de destinatario después de que un proceso obtenga acceso como firmante.

El origen del software registra el origen y el proceso de compilación de un artefacto, proporcionando una forma de evaluar la entrega de la aplicación. El estándar de verificación SLSA requiere validar la firma de origen y el resumen del artefacto, reconocer un constructor de confianza y verificar los parámetros de origen y compilación contra las expectativas. Estas verificaciones pueden ayudar a identificar artefactos sustituidos o fuentes de compilación inesperadas, pero su efectividad depende de los constructores de confianza y las expectativas de origen del verificador. SLSA trata la verificación recursiva de dependencias resueltas como un complemento opcional, por lo que autenticar el artefacto principal no autentica automáticamente cada entrada de compilación. Una aplicación con registros válidos de origen y compilación aún puede contener comportamientos que el usuario rechazaría.

La documentación de la CLI especifica el uso predeterminado de Tor para cierto tráfico no RPC, mientras que el tráfico RPC de Ethereum utiliza la conexión de red normal. Por lo tanto, una interfaz local no hace privadas todas las interacciones externas. Mantener el código de la aplicación y controlar las sustituciones brinda a los usuarios un forma concreta de control, pero el beneficio depende de extender ese control a las elecciones de dependencias y la autoridad de los firmantes.