Ethereum легкий клиент Helios: реализация бездоверительного доступа к Блокчейн
8 ноября был официально запущен новый легкий клиент Ethereum Helios. Этот клиент разработан на языке Rust и предназначен для предоставления полностью бездоверительного доступа к Ethereum.
Одной из основных целей использования Блокчейн является достижение отсутствия необходимости в доверии. С помощью Блокчейн мы можем самостоятельно контролировать свои богатства и данные. В большинстве случаев Блокчейн, такой как Ethereum, действительно сдерживает это обещание: наши активы поистине принадлежат нам.
Однако, ради удобства, мы также сделали некоторые компромиссы. Одним из них является использование централизованного RPC( для удаленного вызова) сервера. Пользователи обычно получают доступ к Ethereum через централизованных провайдеров. Эти компании запускают высокопроизводительные узлы на облачных серверах, помогая всем легко получать данные с цепи. Когда кошелек запрашивает баланс токенов или проверяет статус транзакции, почти всегда используются эти централизованные провайдеры.
Проблема текущей системы заключается в том, что пользователи должны доверять этим поставщикам и не могут проверить, правильны ли результаты запросов.
Helios является легким клиентом Ethereum, основанным на Rust, который обеспечивает полностью доверительный доступ к Ethereum. Он использует протокол легкого клиента, реализованный после перехода Ethereum на PoS, чтобы преобразовать данные от ненадежных централизованных RPC-поставщиков в безопасные и проверяемые локальные RPC. В сочетании с централизованным RPC, Helios может проверять достоверность данных без необходимости запускать полный узел.
Этот клиент может завершить синхронизацию примерно за две секунды и не требует хранения, пользователи могут безопасно получать доступ к данным в цепочке через любое устройство (, включая мобильные телефоны и браузерные плагины ). Но какие потенциальные риски связаны с зависимостью от централизованной инфраструктуры? В следующем разделе будут проанализированы эти риски, представлено решение дизайна Helios и предложены некоторые идеи для улучшения кодовой базы.
Теоретическая форма атаки скрывается в "темном лесу" Ethereum. Она не ищет цели в пуле памяти транзакций, а создает ловушки, имитируя централизованную инфраструктуру, на которую мы полагаемся. Пользователи, даже не совершая ошибок, могут попасть в ловушку: они просто торгуют на DEX, устанавливая разумный проскальзывание... но все же могут столкнуться с новым типом сэндвич-атаки, которая тщательно подготовлена у поставщика RPC.
При обработке сделок на децентрализованных биржах пользователи должны предоставить несколько параметров для смарт-контракта: токены для обмена, сумму обмена и, что наиболее важно, минимальное количество токенов, которое пользователь готов принять. Последний параметр указывает на "минимальный выход", который должен быть достигнут для обмена, иначе сделка будет отменена. Это обычно называется "соскальзыванием", и оно эффективно устанавливает максимальную разницу в цене, которая может возникнуть между отправкой сделки и её подтверждением в блокчейне. Если соскальзывание установлено слишком низко, пользователи могут получить меньше токенов и также могут стать жертвами атаки "сэндвич".
Если минимальные параметры выхода установлены в разумных пределах, это не приведет к атаке сэндвичем. Но что если поставщик RPC не предоставляет точные котировки для смарт-контрактов DEX? Это может ввести пользователей в заблуждение, заставляя их подписывать обменные транзакции с низкими минимальными параметрами выхода. Хуже того, пользователи могут также отправлять транзакции напрямую злонамеренному поставщику RPC. Поставщик может не транслировать транзакцию в публичный мемпул, а вместо этого удерживать ее в тайне и напрямую отправлять атакуемые пакеты транзакций определенным учреждениям для получения прибыли.
Основная причина этой атаки заключается в доверии к другим для получения состояния Блокчейна. Чтобы решить эту проблему, опытные пользователи обычно запускают свои собственные узлы Ethereum, но это требует значительных временных и ресурсных затрат, как минимум, одного устройства, постоянно подключенного к сети, несколько сотен гигабайт места для хранения и примерно одного дня для полной синхронизации с нуля. Хотя в настоящее время порог для запуска узлов снижен, для большинства пользователей это все еще сложно, особенно для пользователей мобильных устройств.
Следует отметить, что атаки со стороны централизованных RPC-провайдеров хотя и возможны, обычно представляют собой простые фишинговые атаки, и описанный нами тип атаки еще не произошел. Хотя прошлые записи основных провайдеров заслуживают доверия, перед использованием незнакомых RPC-провайдеров все же разумно провести дополнительные исследования.
Helios: реализация доступа к Ethereum без доверия
Ethereum запустил протокол легкого клиента, открывая новые возможности для быстрой блокчейн-взаимодействия и проверки RPC-эндпоинтов с минимальными аппаратными требованиями. В течение месяца после The Merge несколько независимых легких клиентов были выпущены подряд, они используют разные методы, но имеют общую цель: обеспечить эффективный доступ без доверия без запуска полных узлов.
Helios — это легкий клиент Ethereum, который может завершить синхронизацию за примерно две секунды, не требуя хранения, и предоставляет полностью доверительный доступ к Ethereum. Как и все клиенты Ethereum, Helios включает в себя уровень исполнения и уровень консенсуса. Но в отличие от большинства клиентов, Helios плотно связывает эти два уровня, позволяя пользователям устанавливать и запускать только одно программное обеспечение.
Принцип работы Helios следующий: уровень консенсуса использует известный хэш блока сигнальной цепи и соединяется с ненадежным RPC, чтобы синхронизироваться с текущим блоком в проверяемом формате. Исполнительный уровень сочетает эти проверенные блоки сигнальной цепи с ненадежным RPC исполнительного уровня, чтобы проверить различные данные о состоянии цепи, такие как баланс счетов, хранилище контрактов, квитанции о транзакциях и результаты вызовов смарт-контрактов. Эти компоненты работают совместно, предоставляя пользователю полностью ненадежный RPC без необходимости запускать полный узел.
уровень консенсуса
Легкий клиент уровня консенсуса следует спецификации легкого клиента Beacon Chain и использует синхронизирующий комитет Beacon Chain. Синхронизирующий комитет состоит из случайно выбранного подмножества из 512 валидаторов и имеет период обслуживания около 27 часов.
После того как валидатор войдет в синхронизационный комитет, он будет подписывать все увиденные заголовки блоков сигналов цепи. Если более 2/3 членов комитета подпишут заголовок блока, то этот блок, скорее всего, находится в стандартной цепи сигналов. Если Helios знает состав текущего синхронизационного комитета, он может надежно отслеживать головную цепь, запрашивая последние подписи синхронизационного комитета.
Благодаря агрегации подписей BLS, для проверки заголовка нового блока требуется всего один запрос. Если подпись действительна и более 2/3 членов комитета подписали, блок будет гарантированно включен в цепочку. Конечно, отслеживание финальности блока может предоставить более сильные гарантии.
В этой стратегии также необходимо решить, как найти текущий синхронизированный комитет. Сначала нужно получить корень доверия, называемый проверкой слабой субъективности. Он представляет собой старый хэш блока, который можно гарантировать, что он был включен в цепь в какой-то момент в прошлом. Что касается времени существования контрольной точки, теоретический анализ показывает, что в худшем случае это примерно две недели, а фактическая оценка может составлять несколько месяцев.
Если контрольная точка слишком старая, теоретически существует возможность атаки, которая может обмануть узлы следовать за ошибочной цепочкой. В этом случае получение контрольной точки слабо субъективности выходит за рамки возможностей протокола. Решение Helios заключается в предоставлении начальной контрольной точки, которая жестко закодирована в кодовой базе (, что легко может быть заменено ), она будет локально сохранять последний окончательный хэш блока, чтобы использовать его в качестве контрольной точки при синхронизации узлов.
С помощью хеширования блоки сигнальной цепи могут легко генерировать уникальный хеш сигнального блока. Это позволяет легко запрашивать полный сигнальный блок, а затем с помощью сравнения хешей доказывать действительность содержимого блока. Helios использует это свойство для получения и проверки ключевых полей в блоках контрольных точек с слабой субъективностью, включая текущий комитет синхронизации и следующий комитет синхронизации. Самое главное, легкий клиент может использовать этот механизм для быстрого просмотра истории блокчейна.
С имеющимся слабым контрольным пунктом субъективности мы можем получить и проверить текущий и следующий синхронный комитет. Если текущая голова цепочки и контрольный пункт находятся в одном и том же цикле синхронного комитета, мы можем немедленно использовать подписанный заголовок синхронного комитета для проверки нового блока. Если контрольный пункт находится после нескольких синхронных комитетов, то можно:
Используйте следующий синхронизационный комитет после контрольной точки для получения и проверки блока, который будет сгенерирован синхронизационным комитетом в будущем.
Используйте этот новый блок для получения следующего синхронизационного комитета.
Если контрольная точка все еще позади, вернитесь к шагу 1.
С помощью вышеуказанного процесса мы можем быстро просматривать историю этого Блокчейна за 27 часов, начиная с хеша любого блока в прошлом и синхронизируя его до текущего хеша блока.
уровень исполнения
Цель легкого клиента уровня исполнения состоит в том, чтобы объединить заголовки блоков сигнальных блоков, проверенные на уровне консенсуса, с ненадежным RPC уровня исполнения, предоставляя проверенные данные уровня исполнения. Эти данные могут быть доступны через локально размещенный RPC-сервер Helios.
Вот простой пример получения баланса счета, сначала кратко расскажем о том, как Ethereum хранит состояние. Каждый аккаунт содержит несколько полей, таких как хеш кода контракта, случайное число, хеш хранилища и баланс. Эти аккаунты хранятся в большой модифицированной дереве Меркла-Патриции, называемом деревом состояния. Как только известен корень дерева состояния, можно проверить доказательство Меркла, чтобы подтвердить, существует ли какой-либо аккаунт в дереве. Это доказательство не может быть подделано.
Helios получает проверенный корень состояния из уровня консенсуса. Путем применения этого корня состояния и запросов Меркле-доказательства к ненадежному уровню выполнения 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 к полному узлу существующего слоя выполнения
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
17 Лайков
Награда
17
4
Репост
Поделиться
комментарий
0/400
BearMarketSurvivor
· 08-09 03:04
Доверительные издержки, наконец, Падение.
Посмотреть ОригиналОтветить0
SerLiquidated
· 08-09 02:01
Необходимо решить проблему централизации.
Посмотреть ОригиналОтветить0
FUDwatcher
· 08-06 03:54
Rust действительно мощный
Посмотреть ОригиналОтветить0
shadowy_supercoder
· 08-06 03:47
Производительность Rust действительно впечатляющая
Helios легкий клиент: реализация полностью доверительного доступа к данным в блокчейне Ethereum
Ethereum легкий клиент Helios: реализация бездоверительного доступа к Блокчейн
8 ноября был официально запущен новый легкий клиент Ethereum Helios. Этот клиент разработан на языке Rust и предназначен для предоставления полностью бездоверительного доступа к Ethereum.
Одной из основных целей использования Блокчейн является достижение отсутствия необходимости в доверии. С помощью Блокчейн мы можем самостоятельно контролировать свои богатства и данные. В большинстве случаев Блокчейн, такой как Ethereum, действительно сдерживает это обещание: наши активы поистине принадлежат нам.
Однако, ради удобства, мы также сделали некоторые компромиссы. Одним из них является использование централизованного RPC( для удаленного вызова) сервера. Пользователи обычно получают доступ к Ethereum через централизованных провайдеров. Эти компании запускают высокопроизводительные узлы на облачных серверах, помогая всем легко получать данные с цепи. Когда кошелек запрашивает баланс токенов или проверяет статус транзакции, почти всегда используются эти централизованные провайдеры.
Проблема текущей системы заключается в том, что пользователи должны доверять этим поставщикам и не могут проверить, правильны ли результаты запросов.
Helios является легким клиентом Ethereum, основанным на Rust, который обеспечивает полностью доверительный доступ к Ethereum. Он использует протокол легкого клиента, реализованный после перехода Ethereum на PoS, чтобы преобразовать данные от ненадежных централизованных RPC-поставщиков в безопасные и проверяемые локальные RPC. В сочетании с централизованным RPC, Helios может проверять достоверность данных без необходимости запускать полный узел.
Этот клиент может завершить синхронизацию примерно за две секунды и не требует хранения, пользователи могут безопасно получать доступ к данным в цепочке через любое устройство (, включая мобильные телефоны и браузерные плагины ). Но какие потенциальные риски связаны с зависимостью от централизованной инфраструктуры? В следующем разделе будут проанализированы эти риски, представлено решение дизайна Helios и предложены некоторые идеи для улучшения кодовой базы.
Потенциальные риски централизованной инфраструктуры
Теоретическая форма атаки скрывается в "темном лесу" Ethereum. Она не ищет цели в пуле памяти транзакций, а создает ловушки, имитируя централизованную инфраструктуру, на которую мы полагаемся. Пользователи, даже не совершая ошибок, могут попасть в ловушку: они просто торгуют на DEX, устанавливая разумный проскальзывание... но все же могут столкнуться с новым типом сэндвич-атаки, которая тщательно подготовлена у поставщика RPC.
При обработке сделок на децентрализованных биржах пользователи должны предоставить несколько параметров для смарт-контракта: токены для обмена, сумму обмена и, что наиболее важно, минимальное количество токенов, которое пользователь готов принять. Последний параметр указывает на "минимальный выход", который должен быть достигнут для обмена, иначе сделка будет отменена. Это обычно называется "соскальзыванием", и оно эффективно устанавливает максимальную разницу в цене, которая может возникнуть между отправкой сделки и её подтверждением в блокчейне. Если соскальзывание установлено слишком низко, пользователи могут получить меньше токенов и также могут стать жертвами атаки "сэндвич".
Если минимальные параметры выхода установлены в разумных пределах, это не приведет к атаке сэндвичем. Но что если поставщик RPC не предоставляет точные котировки для смарт-контрактов DEX? Это может ввести пользователей в заблуждение, заставляя их подписывать обменные транзакции с низкими минимальными параметрами выхода. Хуже того, пользователи могут также отправлять транзакции напрямую злонамеренному поставщику RPC. Поставщик может не транслировать транзакцию в публичный мемпул, а вместо этого удерживать ее в тайне и напрямую отправлять атакуемые пакеты транзакций определенным учреждениям для получения прибыли.
Основная причина этой атаки заключается в доверии к другим для получения состояния Блокчейна. Чтобы решить эту проблему, опытные пользователи обычно запускают свои собственные узлы Ethereum, но это требует значительных временных и ресурсных затрат, как минимум, одного устройства, постоянно подключенного к сети, несколько сотен гигабайт места для хранения и примерно одного дня для полной синхронизации с нуля. Хотя в настоящее время порог для запуска узлов снижен, для большинства пользователей это все еще сложно, особенно для пользователей мобильных устройств.
Следует отметить, что атаки со стороны централизованных RPC-провайдеров хотя и возможны, обычно представляют собой простые фишинговые атаки, и описанный нами тип атаки еще не произошел. Хотя прошлые записи основных провайдеров заслуживают доверия, перед использованием незнакомых RPC-провайдеров все же разумно провести дополнительные исследования.
Helios: реализация доступа к Ethereum без доверия
Ethereum запустил протокол легкого клиента, открывая новые возможности для быстрой блокчейн-взаимодействия и проверки RPC-эндпоинтов с минимальными аппаратными требованиями. В течение месяца после The Merge несколько независимых легких клиентов были выпущены подряд, они используют разные методы, но имеют общую цель: обеспечить эффективный доступ без доверия без запуска полных узлов.
Helios — это легкий клиент Ethereum, который может завершить синхронизацию за примерно две секунды, не требуя хранения, и предоставляет полностью доверительный доступ к Ethereum. Как и все клиенты Ethereum, Helios включает в себя уровень исполнения и уровень консенсуса. Но в отличие от большинства клиентов, Helios плотно связывает эти два уровня, позволяя пользователям устанавливать и запускать только одно программное обеспечение.
Принцип работы Helios следующий: уровень консенсуса использует известный хэш блока сигнальной цепи и соединяется с ненадежным RPC, чтобы синхронизироваться с текущим блоком в проверяемом формате. Исполнительный уровень сочетает эти проверенные блоки сигнальной цепи с ненадежным RPC исполнительного уровня, чтобы проверить различные данные о состоянии цепи, такие как баланс счетов, хранилище контрактов, квитанции о транзакциях и результаты вызовов смарт-контрактов. Эти компоненты работают совместно, предоставляя пользователю полностью ненадежный RPC без необходимости запускать полный узел.
уровень консенсуса
Легкий клиент уровня консенсуса следует спецификации легкого клиента Beacon Chain и использует синхронизирующий комитет Beacon Chain. Синхронизирующий комитет состоит из случайно выбранного подмножества из 512 валидаторов и имеет период обслуживания около 27 часов.
После того как валидатор войдет в синхронизационный комитет, он будет подписывать все увиденные заголовки блоков сигналов цепи. Если более 2/3 членов комитета подпишут заголовок блока, то этот блок, скорее всего, находится в стандартной цепи сигналов. Если Helios знает состав текущего синхронизационного комитета, он может надежно отслеживать головную цепь, запрашивая последние подписи синхронизационного комитета.
Благодаря агрегации подписей BLS, для проверки заголовка нового блока требуется всего один запрос. Если подпись действительна и более 2/3 членов комитета подписали, блок будет гарантированно включен в цепочку. Конечно, отслеживание финальности блока может предоставить более сильные гарантии.
В этой стратегии также необходимо решить, как найти текущий синхронизированный комитет. Сначала нужно получить корень доверия, называемый проверкой слабой субъективности. Он представляет собой старый хэш блока, который можно гарантировать, что он был включен в цепь в какой-то момент в прошлом. Что касается времени существования контрольной точки, теоретический анализ показывает, что в худшем случае это примерно две недели, а фактическая оценка может составлять несколько месяцев.
Если контрольная точка слишком старая, теоретически существует возможность атаки, которая может обмануть узлы следовать за ошибочной цепочкой. В этом случае получение контрольной точки слабо субъективности выходит за рамки возможностей протокола. Решение Helios заключается в предоставлении начальной контрольной точки, которая жестко закодирована в кодовой базе (, что легко может быть заменено ), она будет локально сохранять последний окончательный хэш блока, чтобы использовать его в качестве контрольной точки при синхронизации узлов.
С помощью хеширования блоки сигнальной цепи могут легко генерировать уникальный хеш сигнального блока. Это позволяет легко запрашивать полный сигнальный блок, а затем с помощью сравнения хешей доказывать действительность содержимого блока. Helios использует это свойство для получения и проверки ключевых полей в блоках контрольных точек с слабой субъективностью, включая текущий комитет синхронизации и следующий комитет синхронизации. Самое главное, легкий клиент может использовать этот механизм для быстрого просмотра истории блокчейна.
С имеющимся слабым контрольным пунктом субъективности мы можем получить и проверить текущий и следующий синхронный комитет. Если текущая голова цепочки и контрольный пункт находятся в одном и том же цикле синхронного комитета, мы можем немедленно использовать подписанный заголовок синхронного комитета для проверки нового блока. Если контрольный пункт находится после нескольких синхронных комитетов, то можно:
Используйте следующий синхронизационный комитет после контрольной точки для получения и проверки блока, который будет сгенерирован синхронизационным комитетом в будущем.
Используйте этот новый блок для получения следующего синхронизационного комитета.
Если контрольная точка все еще позади, вернитесь к шагу 1.
С помощью вышеуказанного процесса мы можем быстро просматривать историю этого Блокчейна за 27 часов, начиная с хеша любого блока в прошлом и синхронизируя его до текущего хеша блока.
уровень исполнения
Цель легкого клиента уровня исполнения состоит в том, чтобы объединить заголовки блоков сигнальных блоков, проверенные на уровне консенсуса, с ненадежным RPC уровня исполнения, предоставляя проверенные данные уровня исполнения. Эти данные могут быть доступны через локально размещенный RPC-сервер Helios.
Вот простой пример получения баланса счета, сначала кратко расскажем о том, как Ethereum хранит состояние. Каждый аккаунт содержит несколько полей, таких как хеш кода контракта, случайное число, хеш хранилища и баланс. Эти аккаунты хранятся в большой модифицированной дереве Меркла-Патриции, называемом деревом состояния. Как только известен корень дерева состояния, можно проверить доказательство Меркла, чтобы подтвердить, существует ли какой-либо аккаунт в дереве. Это доказательство не может быть подделано.
Helios получает проверенный корень состояния из уровня консенсуса. Путем применения этого корня состояния и запросов Меркле-доказательства к ненадежному уровню выполнения RPC, Helios может локально проверять все данные, хранящиеся в Ethereum.
Мы используем различные технологии для проверки данных, используемых уровнем исполнения, что позволяет проверять все данные из ненадежных RPC. Ненадежные RPC могут отказать в доступе к данным, но не могут предоставить ошибочные результаты.
Перспективы применения Helios
Трудно совместить удобство и децентрализацию — это общая проблема. С помощью легкого клиента Helios пользователи могут получать доступ к безопасным данным на Блокчейне с любого устройства (, включая мобильные телефоны и браузерные плагины ). Это позволит большему числу людей получать доступ к данным Ethereum без необходимости доверять кому-либо, независимо от используемого оборудования. Пользователи могут использовать Helios в кошельке в качестве RPC-поставщика для получения доступа к различным DApp без необходимости доверия, и весь процесс не требует никаких других изменений.
Кроме того, поддержка WebAssembly в Rust позволяет разработчикам приложений легко встраивать Helios в Javascript приложения (, такие как кошельки и DApp ). Эти интеграции повысят безопасность Ethereum и уменьшат нашу потребность в доверии к централизованной инфраструктуре.
Сообщество может вносить вклад в Helios различными способами, помимо совершенствования кодовой базы, также можно разрабатывать программное обеспечение, интегрирующее Helios, чтобы использовать его преимущества. Вот некоторые потенциальные направления развития: