Ребята, вы в эти дни натыкались на небольшие заметки про Newton Protocol? Их последний главный тезис, который они постоянно повторяют, — это якобы «децентрализованный, верифицируемый слой автоматизации». Звучит же очень мощно, очень в духе Web3, правда?
У меня есть такая привычка: как только вижу какие-то «высокие» слова, мне сразу хочется докопаться до базовой технической архитектуры. В итоге, следуя их же разработческой документации, я все просмотрел и прямо ошарашился. Тут есть один принципиальный логический замкнутый круг, который совсем не сходится: Ньютон каждый день твердит о децентрализации, но в основе, на уровне TEE (доверенной среды выполнения), вся система работает на AWS (облачной платформе Amazon). То есть выходит, что вы думаете, будто доверяете блокчейну, а по факту в конечном итоге все ключи безопасности оказываются у Amazon.
Сегодня поговорим «на пальцах», без фильтров отрасли: сколько же на самом деле тут закопано хитростей в так называемой «децентрализованной автоматизации».
Во‑первых, так называемая «верифицируемость» — в последнем шаге всё-таки нужно смотреть на то, признает ли это AWS
Во-первых, всем нужно понять логику TEE. Код действительно нельзя подменить, а сгенерированные файлы доказательств действительно можно отправить в блокчейн для проверки — звучит безупречно. Но проблема в том, что TEE, который использует Newton, работает внутри AWS Nitro Enclaves на платформе Amazon, и в итоге файл доказательства удалённого измерения (дальней/дистанционно подтверждаемого замера) подписывает AWS!
Что это значит?
AWS признаёт это — и только тогда ваша верификация считается действительной.
Если AWS не «признает» это, или по каким‑то причинам у неё потребуют «не признавать», ваши автоматизированные действия сразу превращаются в шутку.
Разве это не чистой воды «перенос доверия»? Вы просто перекладываете доверие к команде проекта на крупнейшего в мире традиционного интернет‑гиганта — Amazon. Если и это называют децентрализацией, то тогда, может, вообще не стоит играть в блокчейн — давайте просто разрабатывать на серверной инфраструктуре Web2.
Во‑вторых, если случится непреодолимая сила, у Newton вообще нет плана B
Ещё больше настораживает то, что я перевернул официальные технические документы вверх дном — но так и не нашёл ни малейшего описания «резервного аппаратного решения» или механизмов многооблачного отказоустойчивого контура.
Это не просто моя паранойя. Люди, работающие в технике, знают: такая архитектура, где всё сильно зависит от единственного поставщика услуг, — риск, который не решить кодом. Он определяется коммерческими интересами за кулисами или внешней геополитикой.
Представьте крайний сценарий: однажды из‑за требований соответствия политике или по какой‑то причине непреодолимой силы правительство США потребует от AWS содействия в проверке. AWS стоит только «шевельнуть рукой» — остановить выдачу подписей для TEE‑доказательств, которые работают на Nitro Enclaves, — и верификационные возможности всей сети Newton мгновенно полностью парализуются.
Перед лицом такого крайне разрушительного «чёрного лебедя» проектная команда, судя по всему, пока не предусмотрела никаких планов на случай подобных событий.
Кто‑то может возразить: «Хотя бы TEE обеспечивает изоляцию, так что это всё равно лучше, чем полностью полагаться на проектную команду и получать чёрный ящик».
Нельзя сказать, что всё так просто. Когда вы переносите «якорь доверия» с команды проекта на Amazon, вы на самом деле меняете одного «якоря», который вы хотя бы частично понимаете и можете хоть как-то контролировать, на огромную махину, о которой вы знаете ещё меньше и которой вы не можете управлять. Внутренние операционные стратегии AWS, стандарты соответствия, а также история крупных сбоев — обычный пользователь об этом просто не узнает. Сколько раз в истории интернета случались массовые простои AWS? И в какой раз это происходило без того, чтобы в это же время легли сотни и тысячи зависимых от неё интернет‑сервисов? Как только у AWS возникает проблема, TEE‑доказательства вообще не смогут быть сгенерированы, а ваши автоматизированные стратегии просто намертво встанут на полпути — и окажетесь в тупике между «что делать» и «как дальше жить».
В-третьих, цепочка доверия слишком длинная: между всем этим оказываются «аппаратные матрёшки» американских компаний
Вам кажется, что достаточно просто доверять Amazon? Давайте спокойно разберём эту цепочку доверия для TEE — и вы увидите, насколько «матрешка» там глубокая и пугающая.
Ключевая безопасность аппаратного TEE в конечном счёте зависит от корневого ключа, который чип‑производитель внедряет при выпуске устройства с завода. Сейчас на рынке основные аппаратные решения — это Intel (Intel) и AMD. Поэтому, если мы хотим выполнить так называемую «верифицируемую автоматизированную торговлю», реальный путь доверия выглядит так:
Шаг первый: ваши автоматизированные торговые инструкции передаются протоколу Newton.
Шаг второй: Newton запускает стратегии на облачных серверах AWS.
Шаг третий: среда выполнения TEE в AWS использует аппаратные ключи (root keys) Intel или AMD для криптографической изоляции.
Шаг четвёртый: после завершения работы система соответствия (compliance) AWS выдаёт доказательство удалённого замера (attestation).
Шаг пятый: доказательство отправляется обратно в цепочку Newton, завершая последнюю on-chain верификацию.
Давайте посчитаем: целых пять уровней цепочки доверия! Из них только последний уровень — то есть шаг, где производится проверка в цепочке — открыт и прозрачен на блокчейне. Первые четыре уровня (узлы Newton, облачная платформа AWS, чипы Intel, чипы AMD) — это на 100% централизованные сущности. В итоге, мы не просто «доверяем команде Newton», мы начинаем «одновременно доверять Amazon + Intel + AMD». Для криптосообщества, которое стремится к децентрализации, это правда можно назвать улучшением пользовательского опыта?
Четвёртое: «будущее, в котором будет переход», скорее похоже на вечную маниловщину
На самом деле, в сообществе это давно заметили старожилы, и они поставили этот вопрос проектной команде с критикой: «Раз Newton позиционирует себя как децентрализованный автоматизированный слой, почему бы ему самому не собрать распределённый кластер физического оборудования TEE, вместо того чтобы идти по пути наименьшего сопротивления и полагаться на AWS?»
Тогда официальный ответ в общих чертах был таким: «Для эффективности ранней разработки и эксплуатации мы в приоритете выбрали готовое облачное решение. В будущем мы будем постепенно переходить к полностью децентрализованной сети физического оборудования».
И вот это самое интересное: «будущее» — насколько далеко? На три месяца, на год или пока проект не перестанет работать, и этого не будет видно? В своей публичной официальной дорожной карте (Roadmap) Newton не указал ни одного конкретного пункта с временными вехами для жизненно важного «переходного периода к аппаратной децентрализации». То есть до этого момента все «верифицируемые стратегии», которые гоняются по сети и которые так красиво продают, — та самая дверь на выходе, которая всё проверяет, — всё равно прочно удерживается в руках централизованного гиганта.
Подытожим
Сеть, которая громогласно называет себя децентрализованной, но её самый ключевой модуль автоматизированной проверки работает на крупнейшем в мире централизованном облачном сервере — это само по себе колоссальная ирония.
TEE действительно хорошая технология и полезна для приватных вычислений. Но всем нужно сохранять трезвость: сама по себе технология TEE не решает проблему «де‑доверия» (de-trust) в Web3. Она лишь переносит наше доверие «к людям» на «гигантов‑железо‑производителей» и «облачных провайдеров». Если вы в крипто‑сфере играете ради абсолютного контроля и устойчивости к цензуре, то для вас текущая техническая архитектура Newton, которая очень сильно зависит от AWS, — это незаметная, но критическая уязвимость.
(Эта статья — часть платформенных задач и не является какой-либо инвестиционной рекомендацией.)