Віталік Бутерін використовує приватні платежі ethereum за допомогою інструменту Kohaku-cli

Співзасновник ethereum Віталік Бутерін сказав у есе від 31 жовтня, що kohaku-cli обробляв багато платежів Бутеріна, пов’язаних із протоколами конфіденційності. Бутерін також зазначив, що інструмент командного рядка, написаний штучним інтелектом, обробив останні оновлення хешів вмісту IPFS у ENS — системі іменування ethereum. Оновлювач ENS був іншим застосунком, ніж гаманець для платежів. Бутерін не погоджується з веб-сайтами, які надають код застосунку заново під час повторних відвідувань, що робить користувачів постійно залежними від доставки сервера.

Локально збережена програма дозволяє користувачеві зберігати вибрану версію програмного забезпечення та вирішувати, коли встановлювати оновлення. Прийнятий код діє як посередник між інструкціями щодо платежів та підписами, які авторизують платежі, тому залежності та доступ до підписів залишаються важливими. Документація Kohaku-cli описує програму як не перевірену, з підтримкою ШІ та під активною розробкою. Документація рекомендує користувачам не використовувати її на мейннеті, якщо вони не розуміють суті діяльності та ризику катастрофічної втрати коштів. Kohaku-cli підтримує публічні ethereum-акаунти та приватні баланси через Tornado Cash, Railgun та Privacy Pools V1. Гаманець відокремлений від загального набору інструментів Kohaku, що включає бібліотеки протоколів та інфраструктуру гаманця, тому попередження програми не є оцінкою аудиту кожного базового компонента чи протоколу.

Інструкції з встановлення вимагають від користувачів отримати залежності за допомогою npm install, скомпілювати додаток за допомогою npm run build та запустити локальний ланчер. На коміті 0ef5c44 документація, маніфест, файл блокування та реалізація відповідають одній версії додатка. Маніфест вказує версію 0.1.0 та Node.js 22 або новішу, але Бутерін не визначив версію, встановлену для його використання. Маніфест фіксує прямі залежності, включаючи viem та кілька пакетів Kohaku, а також фіксує окрему Git-залежність kohaku-artifacts на коміт. Файл блокування надає вирішені пакети з реєстру та хеші цілісності, що демонструє, що локальний інтерфейс все ще залежить від ланцюжка постачання програмного забезпечення. Тому прийняття заміни через цей процес збірки з джерела передбачає прийняття залежностей та інструментів збірки, а не лише знайомої назви проекту.

Для звичайного публічного переказу без пакетної обробки реалізація симулює транзакцію та отримує результати сухого запуску без надсилання транзакції. Розсилання вимагає приватного ключа відправника та локально створеного клієнта гаманця, чий обліковий запис для підпису походить з цього ключа. Команда Railgun unshield може замість цього створити підготовлений, вже підписаний UserOperation без розсилання операції. UserOperation містить завантаження операції облікового запису, яке сумісні інструменти можуть надіслати, а окрема реалізація розсилання надсилає підписану операцію через Pimlico bundler. Відкладення надсилання не завжди означає відкладення підпису, оскільки сумісні інструменти можуть надіслати підписану операцію пізніше. Створення авторизації, підпис та надсилання представляють різні форми повноважень, навіть якщо єдиний додаток командного рядка координує ці дії.

У перевіреній реалізації публічного переказу правильно налаштований викликатель з доступом до гаманця може поєднати параметри --non-interactive та --broadcast, щоб надіслати транзакцію без додаткового запиту на підтвердження. Вимоги щодо розблокування гаманця, обов’язкових параметрів, відповідності ланцюга та перевірок симуляції залишаються в силі. Ця можливість важлива для скриптів та агентів, але не означає, що Бутерін здійснює платежі без нагляду. У файлі README описується зберігання на диску зашифрованого посіву та файлів паролів, доступ до яких обмежено власником для автоматизації на POSIX. Ці захисти керують зберіганням секретів та доступом до процесів, але самі захисти не накладають незалежних обмежень на витрати чи правила отримувачів після того, як процес отримує доступ до підписувача.

Програмне походження фіксує походження та процес збирання артефакту, надаючи засіб для оцінки доставки застосунку. Стандарт верифікації SLSA вимагає перевірки підпису походження та дайджесту артефакту, визнання довіреного збирача та перевірки параметрів джерела та збирання на відповідність очікуванням. Ці перевірки можуть допомогти виявити підмінені артефакти або неочікувані джерела збирання, але їх ефективність залежить від довірених збирачів та очікувань щодо джерел верифікатора. SLSA розглядає рекурсивну верифікацію вирішених залежностей як додаткову, необов’язкову функцію, тому автентифікація основного артефакту не автоматично автентифікує всі вхідні дані збирання. Застосунок із дійсними записами походження та збирання все ще може містити поведінку, яку користувач відхилить.

Документація CLI вказує на використання Tor за замовчуванням для деякого нерpc-трафіку, тоді як трафік Ethereum RPC використовує звичайне мережеве з’єднання. Тому локальний інтерфейс не робить кожну зовнішню взаємодію приватною. Збереження коду додатка та керування замінами надає користувачам конкретну форму контролю, але користь залежить від поширення цього контролю на вибір залежностей і повноважень підписувачів.