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

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

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

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

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

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

Подводные камни централизованной инфраструктуры: теоретические существа в «темном лесу» Эфириума

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

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

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

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

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

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

Внедрив свой протокол легкого клиента (который стал возможен благодаря недавнему переходу на Proof of Stake), Ethereum открыл новые потрясающие возможности для быстрого взаимодействия с блокчейном и проверки конечных точек RPC с минимальными требованиями к оборудованию. Через месяц с Слияние, мы стали свидетелями появления нового поколения легких клиентов независимо друг от друга (путеводная звезда, Nimbusи основанный на JavaScript Кевлар), которые использовали разные подходы для достижения одной и той же цели: эффективный и не требующий доверия доступ без использования полного узла.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверьте кодовую базу для начала — мы приветствуем ваши отчеты об ошибках, запросы функций и код. А если вы создадите что-то еще, поделитесь этим с нами на Twitter, Telegramили Фаркастер @a16zcrypto.

Мнения, выраженные здесь, принадлежат отдельным цитируемым сотрудникам AH Capital Management, LLC («a16z») и не являются мнением a16z или ее аффилированных лиц. Определенная информация, содержащаяся здесь, была получена из сторонних источников, в том числе от портфельных компаний фондов, управляемых a16z. Хотя информация взята из источников, считающихся надежными, a16z не проводила независимую проверку такой информации и не делает никаких заявлений о текущей или неизменной точности информации или ее уместности в данной ситуации. Кроме того, этот контент может включать стороннюю рекламу; a16z не просматривал такие рекламные объявления и не поддерживает какой-либо рекламный контент, содержащийся в них.

Этот контент предоставляется только в информационных целях и не может рассматриваться как юридическая, деловая, инвестиционная или налоговая консультация. Вы должны проконсультироваться со своими советниками по этим вопросам. Ссылки на любые ценные бумаги или цифровые активы предназначены только для иллюстративных целей и не представляют собой инвестиционную рекомендацию или предложение предоставить консультационные услуги по инвестициям. Кроме того, этот контент не предназначен и не предназначен для использования какими-либо инвесторами или потенциальными инвесторами, и ни при каких обстоятельствах на него нельзя полагаться при принятии решения об инвестировании в какой-либо фонд, управляемый a16z. (Предложение инвестировать в фонд a16z будет сделано только в меморандуме о частном размещении, договоре о подписке и другой соответствующей документации любого такого фонда, и их следует читать полностью.) Любые инвестиции или портфельные компании, упомянутые, упомянутые или описанные не являются репрезентативными для всех инвестиций в транспортные средства, управляемые a16z, и нет никаких гарантий, что инвестиции будут прибыльными или что другие инвестиции, сделанные в будущем, будут иметь аналогичные характеристики или результаты. Список инвестиций, сделанных фондами, управляемыми Andreessen Horowitz (за исключением инвестиций, в отношении которых эмитент не предоставил разрешение на публичное раскрытие информации a16z, а также необъявленных инвестиций в публично торгуемые цифровые активы), доступен по адресу https://a16z.com/investments. /.

Диаграммы и графики, представленные в нем, предназначены исключительно для информационных целей, и на них не следует полагаться при принятии каких-либо инвестиционных решений. Прошлые показатели не свидетельствуют о будущих результатах. Содержание говорит только по состоянию на указанную дату. Любые прогнозы, оценки, прогнозы, цели, перспективы и/или мнения, выраженные в этих материалах, могут быть изменены без предварительного уведомления и могут отличаться или противоречить мнениям, выраженным другими. Пожалуйста, посетите https://a16z.com/disclosures для получения дополнительной важной информации.