Создание Helios: Полностью бездоверительный доступ к Ethereum

На основе статьи

Одна из основных причин, по которой мы используем блокчейн, — это отсутствие доверия. Это свойство обещает предоставить нам независимый доступ к нашим ценностям и данным. По большей части блокчейн, такой как Ethereum, выполняет это обещание — наши активы действительно принадлежат нам.

Однако есть и те факторы, на которые мы пошли ради удобства. Одна из таких вещей — использование централизованных серверов RPC (удаленного вызова команд). Пользователи обычно получают доступ к Ethereum через централизованных провайдеров, таких как Alchemy. Эти компании запускают высокопроизводительные узлы на облачных серверах, чтобы другие могли легко получить доступ к данным цепочки. Когда кошелек запрашивает баланс своих токенов или проверяет, была ли отложенная транзакция включена в блок, он почти всегда делает это через одного из таких централизованных провайдеров.

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

Вводится Helios, разработанный легкий клиент Ethereum на основе Rust, который обеспечивает полностью бездоверительный доступ к Ethereum. Helios — который использует протокол легкого клиента Ethereum, ставший возможным благодаря недавнему переходу на proof of stake — преобразует данные от недоверенного централизованного RPC-провайдера в верифицированно безопасный локальный RPC. Helios работает вместе с централизованными RPC, позволяя проверять их подлинность без запуска фул ноды.

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

Подводные камни централизованной инфраструктуры: теоретические создания в “темном лесу” Ethereum

В темном лесу скрывается (теоретическое) создание. Оно не охотится за своей добычей в mempool Ethereum, а расставляет свои ловушки, имитируя централизованную инфраструктуру, на которую мы привыкли полагаться. Пользователи, попавшие в эту ловушку, не совершают ошибок: Они посещают свою любимую децентрализованную биржу, устанавливают разумную допустимую цену проскальзывания, покупают и продают токены как обычно… Они все делают правильно, но все равно становятся жертвами нового вида атаки-сендвича, ловушки, тщательно расставленной у самого входа в темный лес Ethereum: RPC-провайдеры.

Прежде чем остановиться на этом подробнее, давайте рассмотрим, как работают сделки на децентрализованных биржах. Когда пользователи отправляют своп-транзакцию, они предоставляют смарт-контракту несколько параметров — какие токены нужно обменять, сумму свопа и, самое главное, минимальное количество токенов, которое должен получить пользователь, чтобы транзакция прошла. Последний параметр указывает, что своп должен удовлетворять “минимальному выходу”, или реверсу. Этот параметр часто называют “допустимым проскальзыванием”, поскольку он фактически устанавливает максимальное изменение цены, которое может произойти между моментом отправки транзакции в mempool и моментом ее включения в блок. Если этот параметр установлен слишком низко, пользователь соглашается на возможность получения меньшего количества токенов. Такая ситуация также может привести к атаке типа “сэндвич”, когда злоумышленник эффективно сэндвичит ставку между двумя злонамеренными свопами. Эти свопы повышают спот-цену и вынуждают пользователя совершить сделку по менее выгодной цене. Затем злоумышленник сразу же продает, чтобы получить небольшую прибыль.

До тех пор, пока этот минимальный выходной параметр установлен вблизи справедливого значения, вы защищены от сэндвич-атак. Но что, если ваш провайдер RPC не предоставляет точную ценовую котировку от смарт-контракта децентрализованной биржи? Тогда пользователя можно обманом заставить подписать своп-транзакцию с более низким минимальным выходным параметром, и, что еще хуже, отправить транзакцию прямо вредоносному RPC-провайдеру. Вместо того чтобы транслировать эту транзакцию в публичный мемпул, где десятки ботов соревнуются в выполнении атаки на сэндвич, провайдер может утаить ее и отправить пакет транзакций атаки непосредственно Flashbots, обеспечив себе прибыль.

Основная причина этой атаки — доверие кому-то другому для получения информации о состоянии блокчейна. Опытные пользователи традиционно решали эту проблему, запуская собственные узлы Ethereum — это трудоемкое и ресурсоемкое дело, которое, как минимум, требует постоянно включенной машины, сотен гигабайт памяти и около суток на синхронизацию с нуля. Этот процесс, безусловно, проще, чем раньше; такие группы, как Ethereum on ARM, неустанно работают над тем, чтобы сделать возможным запуск узлов на недорогом оборудовании (например, Raspberry Pi с подключенным к нему внешним жестким диском). Но даже при этих относительно минимальных требованиях запуск узла все еще сложен для большинства пользователей, особенно для тех, кто использует мобильные устройства.

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

Представляем Helios: полностью бездоверительный доступ к Ethereum

Представив протокол легкого клиента (ставший возможным благодаря недавнему переходу на Proof of Stake), Ethereum открыл новые захватывающие возможности для быстрого взаимодействия с блокчейном и верификации конечных точек RPC с минимальными аппаратными требованиями. За месяц, прошедший после The Merge, мы увидели новый ряд легких клиентов, появившихся независимо друг от друга (Lodestar, Nimbus и Kevlar на базе JavaScript), которые использовали различные подходы для достижения одной цели: эффективного и надежного доступа без использования полного узла.

Наше решение, Helios, представляет собой легкий клиент Ethereum, который синхронизируется примерно за две секунды, не требует хранения данных и обеспечивает полностью бездоверительный доступ к Ethereum. Как и все клиенты Ethereum, Helios состоит из уровня исполнения и уровня консенсуса. В отличие от большинства других клиентов, Helios тесно связывает оба уровня, так что пользователям нужно установить и запустить только одну часть программного обеспечения. (Erigon также движется в этом направлении, добавляя легкий клиент уровня консенсуса, встроенный непосредственно в их архивный узел).

Итак, как это работает? Уровень консенсуса Helios использует ранее известный блокчейн цепочки маяков и соединение с недоверенным RPC для верифицированной синхронизации с текущим блоком. Уровень исполнения Helios использует эти аутентифицированные блоки цепи beacon в тандеме с ненадежным RPC уровня исполнения для подтверждения произвольной информации о состоянии цепи, такой как баланс счета, хранение контрактов, квитанции о транзакциях и результаты вызовов смарт-контрактов. Эти компоненты работают вместе, чтобы предоставить пользователям полностью недоверенный RPC, без необходимости запускать полный узел.

…На уровне консенсуса

Легкий клиент уровня консенсуса соответствует специфике легкого клиента beacon chain и использует комитеты синхронизации beacon chain (введенные перед Merge в хард форке Altair). Комитет sync — это случайно выбранное количество из 512 валидаторов, которые работают в течение ~27 часов.

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

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

Однако в этой стратегии есть очевидный недостаток: как найти текущий комитет синхронизации. Это начинается с обретения источника доверия, называемого контрольной точкой слабой субъективности. Пусть вас не пугает это название — оно означает старый блокчейн, который, как мы можем гарантировать, был включен в цепочку в какой-то момент в прошлом. Существует интересная математика, объясняющая, насколько старой может быть контрольная точка; анализ наихудшего случая предполагает около двух недель, в то время как более точные оценки говорят о многих месяцах.

Если контрольная точка слишком старая, существуют теоретические атаки, которые могут обманом заставить узлы следовать по неправильной цепочке. Приобретение слабой контрольной точки субъективности выходит за рамки протокола. Подход с Helios обеспечивает начальную контрольную точку, жестко закодированную в кодовой базе (которую можно легко отменить); затем он сохраняет последний завершенный блокчейн локально, чтобы использовать его в качестве контрольной точки в будущем, когда узел будет синхронизирован.

Удобно, что блоки цепочки beacon могут быть хэшированы для создания уникального beacon blockhash. Это означает, что можно легко запросить у узла полный блок beacon, а затем доказать достоверность содержимого блока путем хэширования и сравнения с известным blockhash. Helios использует это свойство для получения и подтверждения определенных полей внутри блока контрольной точки слабой субъективности, включая два очень важных поля: текущий комитет синхронизации и следующий комитет синхронизации. Очень важно, что этот механизм позволяет легким клиентам быстро просматривать историю блокчейна.

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

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

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

3. Если вы все еще отстаете, вернитесь к шагу 1.

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

… На уровне исполнения

Задача клиента уровня исполнения — принимать заголовки блоков beacon, проверенные уровнем консенсуса, и использовать их вместе с недоверенным RPC для уровня исполнения, чтобы предоставить проверенные данные уровня исполнения. Затем доступ к этим данным можно получить через сервер RPC, локально размещенный в Helios.

Вот простой пример получения баланса счета, начиная с краткого обзора того, как хранится информация в Ethereum. Каждый счет содержит несколько полей, таких как хэш кода проекта, nonce, хэш хранилища и баланс. Эти счета хранятся в большом видоизмененном дереве Merkle-Patricia, которое называется деревом состояний. Если мы знаем корень дерева состояний, мы можем использовать merkle proof для подтверждения существования (или исключения) любого счета в дереве. Эти подтверждения фактически невозможно подделать.

Helios имеет аутентифицированный корень состояния от уровня консенсуса. Используя этот корень и merkle proof запросы к недоверенному RPC уровня исполнения, Helios может локально проверить все данные, хранящиеся на Ethereum.

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

Использование Helios в дикой природе

Компромисс между портативностью и децентрализацией является распространенной болевой точкой — но поскольку Helios настолько легкий, пользователи могут получить доступ к безопасным данным цепочки с любого устройства (включая мобильные телефоны и браузерные расширения). Возможность запуска Helios в любом месте позволяет большему числу людей получить доступ к надежным данным Ethereum независимо от их аппаратного обеспечения. Это означает, что пользователи могут использовать Helios в качестве провайдера RPC в MetaMask и получать безопасный доступ к dapps без каких-либо других изменений.

Кроме того, поддержка WebAssembly в Rust позволяет разработчикам приложений легко встраивать Helios в Javascript-приложения (например, кошельки и dapps). Эти интеграции сделают Ethereum более безопасным и уменьшат нашу потребность доверять централизованной инфраструктуре.

Ждём, что придумает команда. А пока есть множество способов внести свой вклад в Helios — если не интересно вносить вклад в кодовую базу, вы также можете создавать программное обеспечение, интегрированное в Helios, чтобы воспользоваться его преимуществами. Это лишь некоторые из идей, которые можно реализовать:

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

Связь с командой: Twitter, Telegram или Farcaster @a16zcrypto.

Автор перевода Harecrypta

VC | Telegram | Twitter | Youtube | VK | Website