Helius запускает шифрованные платежи в Solana в mainnet, но доверие к оператору остается необходимым

Helius активировала свой бес permission-ный Privacy Ring в mainnet Solana 10 ноября, шифруя активы и суммы платежей, оставляя при этом адреса кошельков отправителя и получателя видимыми. Документированный прувер по умолчанию системы — сервис, создающий доказательства с нулевым разглашением, — добавляет аппаратное требование: секретные входные данные транзакций обрабатываются внутри аттестованного AWS Nitro enclave, изолированной вычислительной среды.

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

Solana может проверить, что перевод соответствует правилам протокола, но защита входных данных во время генерации доказательства зависит от изоляции прувера, его кода и политик развертывания.

Что попадает в сервис доказательств

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

Руководство по интеграции кошелька Helius указывает, что генерация доказательства требует входных данных в открытом виде, охватывающих полные данные транзакции и ключи нуллификаторов, и определяет аттестованный AWS Nitro enclave как прувер по умолчанию для SDK.

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

Эти входные данные становятся доступными для кода доказательства внутри enclave. Документированный клиент защищает их от оператора хоста, шифруя запросы ключом, который хранится в аттестованном enclave. Секрет нуллификатора также порождает маркеры, предотвращающие повторную трату.

В нативной интеграции кошелька кошелек сохраняет ключ подписи, а TypeScript SDK оставляет подписание готовой транзакции Solana за подписывающим компонентом приложения. Helius документирует два режима расшифровки: локальную расшифровку, при которой ключ просмотра остается на устройстве, и делегированную расшифровку, при которой ключ просмотра передается авторизованному провайдеру. Делегирование дает провайдеру доступ на чтение балансов и истории, не предоставляя полномочий на расходование средств.

Как работает модель enclave

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

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

Документированные проверки Privacy Rings проверяют цепочку сертификатов, отклик на запрос и его свежесть, одобренные измерения и привязку ключа шифрования запроса. SDK с тегом отклоняет запрос к удаленному пруверу без аттестации до выполнения любого HTTP-вызова. Кошелек может закрепить проверенную политику выпуска или принять сетевую политику, аутентифицированную закрепленными подписантами SDK. Подписанные политики обновляются во время аттестации и истекают после использования.

На чем по-прежнему основано доверие

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

Согласно руководству по развертыванию Nitro, измеряемый образ включает прувер, стартовый скрипт, набор сертификатов, разрешенные внешние хосты, URL индексатора и идентификатор ключа KMS. Дизайн использует AWS Key Management Service, чтобы предоставлять общий ключ шифрования только enclave с совпадающей аттестацией. Клиенты, как отмечается в руководстве, не могут читать политику ключа KMS и полагаются в этом вопросе на развертывание оператора. В руководстве AWS KMS, AWS Support, аппаратное обеспечение Nitro и оператор называются корнями доверия при начальной привязке политики.

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

Версионированное руководство TEE фиксирует сборку mainnet на основе v0.6.0-alpha с происхождением measured-build, что отличается от документационного тега ts-sdk-v0.8.0-alpha. Спецификация допускает клиентские доказательства, а репозиторий предоставляет инструменты localnet и загружаемые бинарные файлы прувера.

В анонсе запуска Helius говорится, что программы и схемы аудировали Certora, zkSecurity и OtterSec. На странице безопасности указаны аудиты Certora в октябре и zkSecurity в августе, а отчет OtterSec помечен как ожидающийся. Для команд, оценивающих запуск, документированными пунктами для отслеживания являются ожидающийся отчет OtterSec, расхождение между сборкой mainnet v0.6.0-alpha и документационным тегом ts-sdk-v0.8.0-alpha, а также то, используют ли интеграции закрепленные политики выпуска, сетевые политики или клиентский вариант доказательства по спецификации.

Запуск оставляет разработчикам кошельков решение о доверии: какой код и какую политику развертывания они одобряют для обработки входных данных доказательства.

Источник: CryptoNewsNet | Первоначально сообщено CryptoSlate