Краткий обзор

1. Виталик Бутерин заявляет, что использует инструмент kohaku-cli для совершения множества частных транзакций, а также отдельный инструмент, созданный с помощью искусственного интеллекта, для обновления записей в системе ENS.
2. Сохранение локальной версии кошелька может снизить необходимость повторной загрузки кода веб-сайта, при этом решения о загрузке пакетов и обновлениях остаются за пользователем.
3. Подготовка к использованию Railgun для "unshield" (вывода средств) может уже содержать подписанную операцию, поэтому отказ от трансляции не всегда означает отказ от подписи.

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

Его возражение выходит за рамки простого визуального беспорядка. Веб-сайт может повторно предоставлять код приложения каждый раз, когда пользователь возвращается, делая пользователя зависимым от того, что сервер предоставляет каждый раз. Сохранение локальной версии приложения может снизить эту повторяющуюся загрузку. Кроме того, это переносит важное решение на пользователя: какую версию программного обеспечения установить, сохранить и, в конечном итоге, заменить.

Кошелек, о котором он упомянул, иллюстрирует этот компромисс. В его документации содержится предупреждение о том, что CLI не прошел аудит, находится в активной разработке и был создан с помощью искусственного интеллекта. В ней также говорится, что пользователям следует избегать использования основной сети, если они не понимают, что делают, и не осознают возможности катастрофической потери средств.

Контроль над загруженным интерфейсом важен, потому что принятый код находится между инструкцией о платеже и подписью, авторизующей его. Выбор того, когда этот код меняется, может снизить одну из повторяющихся проблем, в то время как его зависимости и доступ к подписи определяют, что может делать установленное программное обеспечение.

Сохранение копии меняет процесс доставки

Практическая выгода заключается в возможности сохранять выбранную версию приложения, а не каждый раз получать веб-интерфейс. Принятие новой версии создает еще одно решение о загрузке. Для этого способа сборки из исходного кода это решение также включает в себя набор зависимостей и инструменты, которые преобразуют исходный код в исполняемое программное обеспечение. Просто знакомое название проекта не описывает весь код, который принимается.

Kohaku-cli обрабатывает публичные аккаунты Ethereum и частные балансы в Tornado Cash, Railgun и Privacy Pools V1. Это конкретное приложение-кошелек, отличное от более широкого набора инструментов Kohaku, включающего в себя многократно используемые протокольные библиотеки и инфраструктуру кошельков. Предупреждение следует рассматривать на уровне этого приложения, а не как вердикт аудита по каждому компоненту или протоколу, который он использует.

Задокументированный процесс установки также показывает, что подразумевается под термином "локальная" установка. Инструкции к проекту предполагают установку зависимостей с помощью npm install, сборку приложения с помощью npm run build и запуск локального запускающего скрипта. В коммите 0ef5c44 документация, манифест, файл блокировок и код описывают одну и ту же версию приложения. Его манифест указывает версию 0.1.0 и требует Node.js версии 22 или выше. Учетная запись Buterin не указывает конкретную установленную версию.

Манифест фиксирует версии прямых зависимостей, включая viem и несколько пакетов Kohaku. Он также привязывает отдельную зависимость Git kohaku-artifacts к определенному коммиту. Соответствующий файл блокировок содержит информацию о разрешенных пакетах из реестра и контрольных суммах. Таким образом, даже когда интерфейс приложения работает на компьютере пользователя, существует цепочка поставок программного обеспечения.

Подготовка может уже включать подпись

Пути public-transfer и Railgun unshield в Kohaku-cli показывают, почему пауза перед отправкой может иметь разное значение. Обычный тестовый запуск public-transfer завершается без отправки транзакции, в то время как предварительно подготовленная операция Railgun unshield может уже содержать подпись.

Для обычного, не пакетного public transfer, реализация передачи имитирует транзакцию и возвращает результат тестового запуска без отправки. Путь отправки требует закрытый ключ отправителя, создает локального клиента кошелька и отправляет транзакцию. Код клиента кошелька получает учетную запись для подписи из этого закрытого ключа.

Приватные операции добавляют дополнительную сложность. Команда unshield может выводить предварительно подготовленную операцию Railgun UserOperation, которая уже подписана, даже если отправка не выполняется. UserOperation – это полезная нагрузка операции учетной записи, которую совместимые инструменты могут отправить. Отдельная реализация отправки ожидает подписанную операцию и затем отправляет ее через Pimlico bundler.

В этом случае, даже если отправка не выполняется, подписанная операция может быть готова для отправки совместимыми инструментами позже. Поэтому термин "подготовлено" не означает, что она универсально не подписана. Необходимо оценивать программное обеспечение, которое может создавать авторизацию, программное обеспечение, которое может ее подписывать, и программное обеспечение, которое может ее отправлять, как отдельные источники полномочий, даже если одна командная строка координирует их работу.

Подтверждение действиями пользователя – это еще один отдельный вариант. В проанализированном сценарии публичной передачи, правильно настроенный клиент с доступом к кошельку может использовать параметры --non-interactive вместе с --broadcast для отправки транзакции без запроса дополнительного подтверждения. Требования к разблокировке кошелька, необходимые параметры, проверка соответствия сети и симуляция по-прежнему применяются. Эта возможность актуальна для скриптов и агентов; она не раскрывает, использует ли Бутерин автоматические платежи.

В файле README описано использование зашифрованного ключа на диске и файлов паролей с ограниченным доступом для автоматизации POSIX. Эти меры регулируют хранение секретных данных и способы получения процессом доступа к ним. Однако сами по себе они не устанавливают независимый лимит расходов или политику назначения получателя, как только процесс получает доступ к подписи.

Ранее CryptoSlate освещала проблему разрешений кошельков для локального ИИ. Контроль доставки добавляет еще один аспект: пользователь может сохранить выбранную версию интерфейса, в то время как этот код работает в рамках предоставленных ему полномочий по подписи и отправке.

Проверка происхождения позволяет установить источник и содержит отдельный вопрос о поведении.

Проверка происхождения программного обеспечения позволяет более тщательно изучить процесс доставки. Она регистрирует, откуда взялся компонент и как он был создан. Стандарт проверки SLSA описывает проверку подписи происхождения, сравнение хеша компонента, идентификацию доверенного создателя и сопоставление указанного источника и параметров сборки с ожидаемыми значениями.

Эти проверки могут помочь отличить ожидаемую сборку от подмененного компонента или источника сборки, который не был предусмотрен. Однако они по-прежнему зависят от того, каким создателям и источникам сборки доверяет проверяющий.

Проверка зависимостей остается отдельной задачей. SLSA описывает рекурсивную проверку разрешенных зависимостей как необязательный дополнительный шаг. Аутентификация основного компонента не означает автоматическую аутентификацию всех его входных данных.

Правильное происхождение и история сборки могут сопровождать логику приложения, которую пользователь все равно может отклонить.

Конфиденциальность сети также является отдельной от процесса доставки приложения. Документация CLI описывает использование Tor по умолчанию для определенного трафика, отличного от RPC, в то время как Ethereum RPC использует обычное сетевое соединение. Следовательно, запуск интерфейса локально не делает все внешние взаимодействия конфиденциальными. Ранее Kohaku и отчет о проверенном RPC касались другой части этой более широкой проблемы доверия.

Эксперимент, проведенный Бутериным, указывает на конкретную форму контроля со стороны пользователя: выбор кода приложения, который остается на устройстве, и принятие решения о том, когда принимать обновленный код. Ценность этой системы заключается в том, что контроль сохраняется на всех этапах, включая выбор зависимостей и проверку подписи.

Контекст статьи.