Виталик делает частные платежи в Ethereum без крипто-сайта

Виталик Бутерин перемещает часть своей активности в 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 или новее. Учетная запись Бутерина не указывает его установленную версию.

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

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

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

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

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

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

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

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

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

Проверка происхождения, с отдельным вопросом о поведении

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

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

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

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

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

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

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