Пересылка оригинального заголовка «TeleportDAO: борьба за безопасность и эффективность проверки данных - последние практические разработки для легкого узла»

TL;DR

TeleportDAO и Eigen Labs недавно совместно опубликовали статью, посвященную проблемам безопасности и эффективности, с которыми сталкиваются легкие узлы при доступе и проверке данных on-chain в блокчейнах с механизмом Proof-of-Stake (PoS). В этой статье предлагается новое решение для обеспечения безопасности и эффективности легких узлов в блокчейнах PoS через ряд мер, таких как экономические стимулы и застрахованные предварительные механизмы безопасности, а также индивидуализированная «программируемая безопасность» и экономичность. Это очень перспективно и заслуживает глубокого изучения.

Примечание: Eigen Labs - разработчик протоколов Restaking EigenLayer и EigenDA. Eigen Labs на данный момент привлек более 150 миллионов долларов США от известных венчурных капиталовложений, таких как a16z, Polychain и Blockchain Capital.

TeleportDAO находится в Ванкувере, Канада. Это проект инфраструктуры кросс-чейн коммуникации, сфокусированный на общественных цепях Bitcoin и EVM. Протокол успешно привлек $9 миллионов в раунде публичных продаж и финансирования через Coinlist. В этом раунде финансирования приняли участие несколько инвесторов, включая Appworks, OIG Capital, DefinanceX, Oak Grove Ventures, Candaq Ventures, TON, Across и bitSmiley.

Проблемы существующего дизайна легкого узла

В настоящее время, в блокчейнах PoS валидаторы участвуют в сети консенсуса, блокируя определенное количество стейкинга (например, 32 ETH в Ethereum), чтобы обеспечить безопасность сети. Таким образом, сущность безопасности блокчейна PoS защищена экономикой, то есть, чем больше общий стейк, тем больше стоимость или потери требуются для атаки сети консенсуса. Реализация этого механизма снижения надежности зависит от функции, называемой «ответственность за безопасность», то есть, если валидатор подписывает противоречивое состояние, стейк можно сократить.

Полные узлы играют важную роль в поддержании целостности блокчейна PoS. Они хранят всю информацию о блоках, проверяют подписи согласия, реплицируют полную копию истории транзакций и выполняют обновление состояния. Для этих процессов требуются значительные вычислительные ресурсы и сложное оборудование. Например, для работы полного узла Ethereum требуется как минимум 2 ТБ SSD-накопителя. В отличие от этого, легкие узлы снижают требования к вычислительным ресурсам и хранят только заголовки блоков, поэтому они подходят только для сценариев, где проверяются конкретные транзакции/статусы, таких как мобильные кошельки и кросс-цепные мосты. Кроме того, легкие узлы полагаются на полные узлы для предоставления информации о блоках при проверке транзакций, но текущая доля рынка провайдеров услуг узлов относительно концентрирована, поэтому безопасность, независимость и мгновенность не могут быть полностью гарантированы. Поэтому в данной работе исследуется компромисс между стоимостью сбора данных и задержкой для легких узлов для достижения оптимальной безопасности.

Существующие решения дизайна светового узла

Биткойн представил Простую Проверку Платежей (SPV) в качестве своего протокола легкого узла. SPV позволяет легким узлам использовать доказательство Merkle и заголовки блоков для проверки включения транзакции в конкретный блок. Следовательно, легким узлам достаточно загрузить заголовок блока блокчейна для проверки окончательности транзакции, проверив глубину блока. В этом случае вычислительные затраты проверки согласия легкими узлами в Биткойне относительно низкие. Однако в блокчейнах PoS, таких как Ethereum, дизайн проверки согласия по своей сути более сложен. Это включает в себя поддержание полного набора валидаторов, отслеживание изменений их доли и выполнение множества проверок подписей для сети согласия. С другой стороны, безопасность легких узлов PoW зависит от предположения, что большинство полных узлов честны. Для решения ограничений SPV FlyClient и Non-Interactive Proof of Work (NiPoPoW) доказывают эти блоки клиентам по сублинейной стоимости. Однако их применимость к модели согласия PoS слаба.

В отличие от них, блокчейны PoS обеспечивают безопасность за счет механизмов слэшинга. Система полагается на то, что участники консенсуса будут рациональны и не будут атаковать сеть, если стоимость атаки превысит любую потенциальную прибыль. Чтобы снизить затраты на верификацию, текущий протокол легкого узла Ethereum полагается на комитет по синхронизации, состоящий из 512 случайно выбранных валидаторов Ethereum, каждый из которых стейкает 32 Ethereum, но процесс подписания не будет оштрафован. Эта неразрезаемая конструкция имеет серьезный недостаток безопасности, а нечестные подписи в комитете по синхронизации могут ввести в заблуждение легкие узлы, заставив их принимать недействительные данные без наказания. Даже с введением механизмов слэшинга общая доля Sync Committee все еще невелика по сравнению с огромным пулом валидаторов Ethereum (по состоянию на март 2024 года количество валидаторов Ethereum превысило 1 миллион). Таким образом, такой подход не может обеспечить легкие узлы безопасностью, эквивалентной набору валидаторов Ethereum. Эта модель представляет собой особый вариант многосторонних вычислений в рациональных условиях, но не обеспечивает экономических гарантий и не устраняет угрозы, исходящие от злонамеренных, иррациональных поставщиков данных.

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

Другой подход к исследованиям сосредоточен на использовании доказательств с нулевым разглашением для создания кратких доказательств. Например, Mina и Plumo эффективно облегчают верификацию легкого консенсуса с использованием рекурсивной композиции SNARK и доказательств основанного на SNARK перехода состояния. Однако эти подходы накладывают значительную вычислительную нагрузку на производителей блоков для генерации доказательств, и они не решают проблему компенсации легких узлов за потенциальные потери. В контексте других протоколов PoS, таких как протокол Tendermint, используемый в Cosmos, рассматривается роль легких узлов в их протоколе межблокчейн-коммуникации (IBC). Однако эти реализации специфичны для своих соответствующих экосистем и не применимы непосредственно к Ethereum или различным другим PoS блокчейнам.

Новый дизайн узла света

В общем, новое решение вводит экономический модуль безопасности для достижения "программируемой безопасности", и легкие узлы могут принимать решения о различных конструкциях решений на основе своих потребностей в безопасности. Предположение о безопасности в основном составляет 1/N + 1/M, то есть, при наличии честного и действительного узла в полном узле и сети прокуроров, нормальная работа сети может быть гарантирована.

Связанные модули/роли

• Блокчейн: Протокол построен на программном блокчейне, и правила завершения блоков детерминированы. Например, на блокчейне Ethereum завершение блока требует как минимум двух последующих эпох, что обычно занимает около 13 минут.
• Смарт-контракт санкций: протокол включает в себя цепочечный контракт санкций, который соответствует стандартной абстракции смарт-контракта. У него есть доступ к хэшу блока предыдущего блока в блокчейне. Все стороны могут отправлять сообщения этому контракту.
• Поставщики данных: Поставщики данных запускают полные узлы и отслеживают последнее состояние блокчейна. Они обещают активы и предоставляют услуги по проверке достоверности запрошенного состояния легкими узлами. Они подписывают все данные, отправленные легким узлам, секретным ключом, соответствующим их открытому ключу, тем самым проверяя источник и целостность данных.
• Прокуроры: Прокуроры - это полные узлы, подключенные к легким узлам для помощи в верификации данных. Любой может стать прокурором и получать прибыль, мониторя и нанося удары по сторонам, которые ведут себя неправильно. Для упрощения предполагается, что каждый легкий узел подключен по крайней мере к одному честному прокурору.
• Легкий Узел: Легкий узел проверяет, включено ли определенное состояние/транзакция в блокчейн по минимальной цене. В процессе верификации легкий узел соединяется с группой поставщиков данных и прокуроров.
• Сеть: Поставщики данных формируют сеть равноправных (p2p) и используют протокол Gossip для распространения данных. Легкие узлы подключаются к некоторым поставщикам данных для отправки запросов и получения ответов.

Вариант 1: Сначала безопасность

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

Конкретный процесс запроса данных световым узлом:

1. Легкий узел получает последний список поставщиков данных из текущей сети и определяет период вызова. Следует отметить, что этот период вызова является независимым среди различных легких узлов, но верхний предел периода вызова применяется ко всем легким узлам. Период вызова является самым длительным временем для сети прокуроров для проверки достоверности данных, поэтому чем дольше время, тем дольше задержка на каждую транзакцию.
2. Получив список, легкий узел выберет группу поставщиков данных и убедится, что их ставки больше стоимости текущей транзакции. Теоретически, чем выше ставка, тем выше стоимость недобросовестного поведения поставщика данных и ниже доверительные расходы легкого узла.
3. Легкий узел отправляет соответствующий запрос на данные этой группе поставщиков данных, включая соответствующий номер блока и целевое состояние (доказательство включения этой транзакции).
4. Поставщик данных отправляет соответствующий хэш блока и доказательство включения транзакции, а также прикрепляет подпись.
5. После того, как узел света получает вышеупомянутые материалы, он пересылает их текущей подключенной сети прокуроров. Если после окончания периода оспаривания не поступает предупреждение о достоверности данных, узел света проверит эту подпись и пройдет тест на достоверность данных, если ошибок нет.

1. Но если сеть прокуроров получает предупреждение, легкому узлу необходимо отбросить ранее полученную подпись. Сеть прокуроров предоставит соответствующее доказательство в модуль штрафов смарт-контракта. Если смарт-контракт обнаруживает, что нарушение действительно произошло после проверки данных, ставка соответствующего поставщика данных будет оштрафована. Поскольку часть/все выбранные поставщики данных были оштрафованы, легкому узлу необходимо повторно получить новый список поставщиков данных из текущей сети, чтобы подтвердить, что событие сокращения действительно произошло.

Другие моменты:

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

Оценить:

• Безопасность: Легкий узел определяет стоимость злонамеренного поведения для рациональных и иррациональных поставщиков данных через модуль стейкинга и сеть прокуроров, повышая доверие к данным. Однако, поскольку вся протокол основан на сети консенсуса (этот документ тестируется на Ethereum), если слой консенсуса подвергается атаке, протокол также может столкнуться с потенциальным кризисом доверия. Поэтому механизм репутации может быть введен дополнительно для обеспечения системного риска в экстремальных ситуациях.
• Безопасность на уровне полного узла: Эта схема нацелена на обеспечение безопасности, эквивалентной предположению PoS Ethereum, то есть полные узлы должны нести риск сокращения за ложные утверждения.
• Активность сети: если в текущей сети есть всего лишь несколько рациональных поставщиков данных, то легкий узел столкнется с несколькими раундами задержки, но поскольку пропускная способность каждого поставщика данных не равна нулю, каждый запрос всегда будет завершен. Таким образом, при наличии хотя бы одного рационального полного узла в сети можно гарантировать ее непрерывную работу. В то же время поскольку доход поставщиков данных связан с объемом стейкинга, это также стимулирует полные узлы защищать сеть, стейкая больше, чем требуется.
• Эффективность: Команда авторов статьи предсказывает, что узлы Ethereum являются основными пользователями, участвующими в предоставлении данных, поскольку узлы уже работают в полном объеме и могут получать дополнительный доход благодаря этому протоколу. Маленькие транзакции могут получать достоверные данные через одного поставщика данных (легкий узел должен проверить только один раз), тогда как для крупных транзакций может потребоваться несколько поставщиков данных для получения достоверных данных (количество проверок линейно увеличивается с числом поставщиков).

Вариант 2: Сначала эффективность

Решение 2 обеспечивает быстрое подтверждение данных, предлагая механизм страхования на основе Решения 1. Простыми словами, после того как легкий узел определит страхование в соответствии с суммой и продолжительностью полиса, часть / весь залог от поставщика данных может быть возмещен за последующие потери легкого узла из-за злонамеренных данных. Поэтому, после того как легкий узел получит и проверит подпись данных, предоставленную поставщиком, он может определить начальную достоверность данных.

Конкретный процесс запроса данных легким узлом:

1. Легкий узел вычисляет максимальную потенциальную потерю текущей транзакции, а затем устанавливает сумму страхового полиса и срок страхования. Сумма средств, заложенных поставщиком данных для страхования, должна быть больше суммы страхового полиса, чтобы обеспечить достаточные средства для погашения.
2. Легкий узел определяет период вызова для транзакции. Следует отметить, что период политики может охватывать проверки включения нескольких транзакций, поэтому общий выбранный период вызова легким узлом не может превышать период политики, в противном случае некоторые транзакции могут остаться без покрытия.
3. После выбора параметров (сумма полиса, срок действия полиса, сумма средств, заложенных поставщиком данных для страхования, список намеренных поставщиков данных) легкий узел может отправить запрос на смарт-контракт. Затем, дождавшись завершения последнего времени подтверждения блока, он может проверить успешна ли покупка страхования. Если это не удается, это может быть потому, что другие легкие узлы также выбрали поставщика данных и заключили сделку первыми, поэтому оставшаяся залоговая сумма недостаточна для удовлетворения его первоначального требования.
4. Легкий узел отправляет запрос данных, включающий номер страховки, а также номер блока и целевое состояние (доказательство включения транзакции).
5. Поставщик данных отправляет данные и подпись, световой узел проверяет подпись и пересылает ее в сеть прокурора, а затем транзакция была предварительно подтверждена.
6. Получив данные и подпись, прокурор сначала проверит достоверность данных. Если есть злонамеренное поведение, прокурор предоставит доказательства смарт-контракту и наложит штраф на соответствующего поставщика данных, который будет распределен на легкие узлы.

Другие моменты:

• Ставки страховых токенов поставщика данных независимы друг от друга между различными запросами от легкого узла, чтобы предотвратить риск множественных выплат страхования. После того, как легкий узел выберет поставщика данных, смарт-контракт заблокирует соответствующие токены, заложенные для страхования, и другие легкие узлы не смогут выделить эту часть залога до окончания периода страхования. Если транзакции независимы, сумма страхования равна максимальной сумме транзакции. В противном случае сумма страхования равна общей сумме транзакции. При одинаковой сумме залога легкие узлы обычно выбирают как можно меньше поставщиков данных, чтобы обеспечить эффективность проверки.
• Хотя поставщик данных может инициировать запрос на "вывод" до окончания периода страхования, сумма вывода будет получена только после окончания периода страхования.
• Строго говоря, период страхования должен быть больше времени подтверждения последнего блока + общего периода вызова + задержки в коммуникации + задержки в расчете/проверке. Чем больше поставщиков данных вы выбираете, тем длиннее будет период страхования на основе общего периода вызова.

Оценить:

• Масштабируемость: Масштабируемость Опции 2 определяется общим количеством токенов, на которые поставщики данных готовы пойти на страховку.
• Стоимость полиса: поскольку более высокие уровни безопасности связаны с циклом вызовов, это означает, что поставщик данных должен заложить на период, больший или равный циклу вызовов. Следовательно, чем выше требования к безопасности, тем длиннее цикл залога и тем больше платит световой узел. Согласно формуле, стоимость залога поставщика данных рассчитывается как доход узла поставщика данных / (среднее использование залога в течение года, умноженное на общее количество блоков в году). Цена, которую должен заплатить световой узел, равна стоимости залога, умноженной на период и размер полиса.

Эффективность решения

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

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

Во-первых, в плане затрат на легкие узлы, на самом деле существует две статьи расходов на легкие узлы: плата за газ и страховая премия, обе из которых будут увеличиваться по мере увеличения суммы страховой полис. Кроме того, для инспекторов газ, связанный с представлением данных, будет возмещен суммой штрафа, чтобы обеспечить достаточные стимулы для участия.

Направление расширения

• Больше Залогов: В настоящее время токен, заложенный поставщиками данных, является ETH, но информация о транзакциях рассчитывается на основе стандарта U, что означает, что легким узлам необходимо измерять курс ETH каждый раз при получении данных, чтобы гарантировать, что сумма залога достаточно высока. Если разрешено залагать несколько токенов, поставщики данных могут иметь больше вариантов залога, тем самым избегая риска, связанного с одной валютой.
• Авторизация: Подобно совместному майнингу, некоторые розничные инвесторы могут принять участие в сети поставщиков данных, авторизовав свой собственный ETH на полный узел, и прибыль распределяется в соответствии с их собственным соглашением. Пожалуйста, обратитесь к LSD.
• Гарантия блока: Чтобы избежать ожидания окончательного периода подтверждения (12-13 секунд в Ethereum), легкие узлы могут использовать гарантию, чтобы сократить это время ожидания. Световой узел сначала добавит символ/идентификацию при запросе данных и определит, какая гарантия требуется (окончательное подтверждение/предложение). Поставщик данных предоставляет соответствующие данные и подпись после получения запроса. Если у поставщика данных нет предлагаемой блокировки в ситуации «предлагаемой гарантии», он будет оштрафован. \
  \
  Примечание: Предполагаемые блоки в конечном итоге будут завершены или станут блоками-дядьями.
• Стоимость и сборы: Для сети прокуроров им необходимо заложить определенное количество токенов (больше, чем газ), чтобы предоставить доказательства в смарт-контракт. Кроме того, стоимость этой части доказательства может быть снижена с помощью метода zkp. Кроме того, в рамках механизма страхования премии, представленные световыми узлами, будут переданы поставщикам данных, в то время как сеть прокуроров извлечет часть штрафного дохода от злонамеренных поставщиков.
• Доступность данных: Поставщики данных по сути являются полными узлами. Помимо участия в сети уровня консенсуса, они также могут проверить доступность данных. Существуют два типа схем для проверки доступности: модель извлечения и модель распределения. Первая относится к тому, что легкий узел случайным образом извлекает данные, полученные от полного узла. Вторая относится к тому, что производитель блока распределяет различные блоки поставщикам данных. Для поставщиков данных, которые принимают модель извлечения, они несут ответственность за возврат запросов выборки. После получения данных легкий узел пересылает их доверенному узлу/валидатору, и они пытаются восстановить блок. Если им это не удается, поставщику данных будет наложен штраф. Протокол легкого узла в данной статье предлагает механизм страхования на этой основе, обеспечивая новое направление исследований доступности данных.

Заключение и оценка

Предложенное в этой статье решение для легкого узла обеспечивает "программируемую безопасность" для удовлетворения требований безопасности в различных ситуациях. Вариант 1 торгует более высокой задержкой ради высокой безопасности, в то время как вариант 2 предоставляет услуги "мгновенного подтверждения" для легких узлов путем введения механизма страхования. Эти решения могут использоваться в сценариях, где необходимо подтверждение окончательности транзакций, таких как атомарные транзакции и межцепочные операции.

Отказ от ответственности:

1. Эта статья перепечатана с [Партнеры Eureka].Пересылка оригинального заголовка 'TeleportDAO: борьба между безопасностью и эффективностью проверки данных - последние практики в дизайне легких узлов'. Все авторские права принадлежат оригинальному автору [Andy、Arthur]*. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они быстро справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. За исключением упоминания, копирование, распространение или плагиат переведенных статей запрещены.