Виталик Бутерин использует частные платежи на 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 использует обычное сетевое соединение. Следовательно, локальный интерфейс не делает все внешние взаимодействия приватными. Сохранение кода приложения и управление заменами предоставляют пользователям конкретную форму контроля, но польза зависит от распространения этого контроля на выбор зависимостей и полномочия подписывающих лиц.