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

8 ноября одна известная венчурная компания представила легкий клиент Ethereum Helios. Этот клиент, написанный на языке Rust, предназначен для обеспечения полностью доверительного доступа к Ethereum.

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

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

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

Helios является легким клиентом Ethereum, основанным на Rust, который может предоставить полностью бездоверительный доступ к Ethereum. Он использует протокол легкого клиента, реализованный после перехода Ethereum на PoS, который может преобразовывать данные от ненадежных централизованных поставщиков RPC в безопасные и проверяемые локальные RPC. В сочетании с централизованным RPC Helios может проверять подлинность данных без необходимости запуска полного узла.

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

Потенциальные риски централизованной инфраструктуры: теоретические угрозы в экосистеме Ethereum

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

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

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

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

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

Введение в Helios: доступ к Ethereum без необходимости доверять

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

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

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

уровень консенсуса

Легкий клиент уровня согласия следует стандартам легкого клиента сигналов цепи и использует синхронизационный комитет сигналов цепи (введенный в хардфорке Altair до слияния). Синхронизационный комитет состоит из случайно выбранного подмножества из 512 валидаторов, период обслуживания составляет примерно 27 часов.

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

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

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

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

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

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

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

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

3. Если контрольная точка все еще позади, вернитесь к шагу 1.

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

уровень исполнения

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

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

Helios получил проверенный корень состояния из уровня консенсуса. Применяя этот корень состояния и запрос доказательства Merkle к незащищенному RPC уровня исполнения, Helios может локально проверять все данные, хранящиеся в Ethereum.

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

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

Трудно совместить удобство и децентрализованность, что является общепризнанной проблемой. С помощью легкого клиента Helios пользователи могут безопасно получать доступ к данным в блокчейне с любого устройства (включая мобильные телефоны и плагины для браузеров). Это позволит большему числу людей получать доступ к данным Ethereum без необходимости доверять кому-либо, независимо от аппаратных ограничений. Пользователи могут настроить Helios в некоторых кошельках в качестве поставщика RPC, чтобы получать доступ к различным DApp без необходимости доверять, при этом весь процесс не требует никаких других изменений.

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

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

• Поддержка прямого получения данных легкого клиента из P2P сети (вместо RPC)
• Реализовать некоторые еще не поддерживаемые методы RPC
• Разработка версии Helios, которую можно скомпилировать в WebAssembly
• Интегрировать Helios напрямую в программное обеспечение для кошельков
• Создайте сетевую панель для просмотра балансов токенов и встроите Helios в веб-сайт с использованием WebAssembly для получения данных
• Развернуть API движка, подключить уровень консенсуса Helios к полному узлу существующего уровня исполнения