Введение
В последние месяцы наблюдается значительный интерес к Optimistic Rollup (OR), платформе масштабируемости, основанной на защите от мошенничества (FP). Мы в StarkWare внедряем Validity Proofs (VP), потому что они более безопасны, чем FP . В этом посте указывается на несколько дополнительных преимуществ, которыми VP обладает по сравнению с OR, и исправляются распространенные заблуждения о VP и о StarkEx — механизме масштабирования VP на основе StarkWare STARK.
В частности, по сравнению с OR, VP это:
- Принципиально более безопасный
- В 1000 раз более эффективно использовать средства для снятия средств
- Более масштабируемый (в сети)
- По крайней мере, так же эффективно, в вычислительном отношении
Безопасность
В нашем предыдущем анализе мы сравнили VP, где переходы между состояниями происходят строго через допустимые состояния, с OR, где разрешен любой переход между состояниями (отсюда: оптимистичный), и участники могут представить доказательства мошенничества, т.е. недопустимых переходов между состояниями. Наш анализ был, по сути, анализом безопасности и указывал на четко определенную атаку на ОР, атаку, которая приводит к краже всех средств из ОР ( дополнительные возможные атакипродолжают обсуждаться). Инфраструктурные решения, предлагаемые для блокчейнов, должны быть достаточно устойчивыми, чтобы выдерживать полную нагрузку финансового мира, где ежедневно совершаются операции с T$. Как VP и OR соответствуют этой задаче? Поскольку стоимость кражи средств из ОР не связана с размером вознаграждения, разумные агенты обязаны сломать систему, как только в нее будет вложена существенная ценность. Напротив, VP нельзя перевести в недопустимое состояние, а средства нельзя украсть, независимо от размера вознаграждения. Для крупных финансовых систем VP устойчива, OR, скорее всего, сломается.
Безопасность также можно анализировать на основе роли данных и последствий их отсутствия. В OR данные играют гораздо более опасную роль, чем в VP. При отсутствии данных средства в OR могут быть украдены — по этой причине текущие проекты сосредоточены на DA в цепочке. В VP с данными в цепочке (например, ZK-Rollup) средства так же безопасны, как и сам уровень 1. В VP с данными вне сети средства можно просто заморозить, а не украсть.
Эффективность капитала
Одной из болезненных проблем с ликвидностью криптовалюты является задержка, связанная с выводом средств. В OR стандартное окно вывода средств составляет ~1 неделю — ожидаемая продолжительность предоставления доказательств мошенничества (параметр безопасности). В VP стандартное окно вывода составляет ~ 10 минут (и, вероятно, намного меньше, с дополнительными программными и аппаратными улучшениями) — продолжительность создания доказательства, подтверждающего целостность последних вычислений. Таким образом, стандартное окно вывода средств для OR в 1000 раз больше, чем для VP (например, 1 неделя / 10 минут ~ 1000). Этот 1000-кратный штраф должен быть выплачен при использовании ИЛИ, независимо от того, выражается ли этот штраф в эффективности капитала или в продолжительности.
Ранее мы описывали не требующий доверия механизм быстрого вывода средств , при котором пользователь, желающий быстро вывести средства, отдает поставщику ликвидности подписанный условный платеж — долговую расписку — за средства вне сети , и, в свою очередь, получает выплату — на скорости сети — то же самое. сумма в цепочке , из смарт-контракта «cookie jar» поставщика ликвидности. Поставщик ликвидности может периодически пополнять свою «кувшинку с печеньем» за счет средств, накопленных на балансе вне сети.
Быстрый вывод можно использовать как для VP, так и для OR . Но для OR поставщик ликвидности должен держать в 1000 раз больше капитала в своей «кувшине с печеньем», поскольку ему необходимо обслуживать запросы, полученные в течение окна, которое в 1000 раз больше. Это соотношение не зависит от каких-либо предположений, которые мы делаем в алгоритме для определения ликвидности, необходимой в «кувшине с печеньем»: основано ли оно на ожидаемом снятии средств или только на снятии средств за вычетом депозитов; основано ли оно на пиковых требованиях к ликвидности или только на каком-то среднем/вероятном случае.
К сожалению, быстрый вывод средств не всегда является жизнеспособным вариантом. При работе с невзаимозаменяемыми активами (или просто меньшими наборами взаимозаменяемости) они невозможны (или, вероятно, будут значительно дороже):
- Незаменяемые токены (NFT): как впервые описал Виталик, если ценный крипто-котенок, назовем ее Митци, хранится вне сети, ее владелец не может попросить получить ее в сети, поскольку в сети есть только одна Митци. Мир.
- Экранированные транзакции: обязательство в стиле Zerocash также в некотором смысле невзаимозаменяемо. Чтобы активировать быстрый вывод при перемещении защищенного токена обратно в основную цепочку, где он должен оставаться защищенным, пользователь должен будет раскрыть конкретное обязательство перед поставщиком ликвидности.
В этих случаях, когда быстрый вывод средств недоступен, пользователи вернутся к стандартному окну вывода средств, который в 1000 раз быстрее для VP, чем для OR.
Масштабируемость (в сети)
В этом разделе, чтобы сравнивать яблоки с яблоками, мы будем рассматривать только накопительные системы, где по определению данные доступны в сети: OR против STARK ZK-Rollup (StR). Любое решение, которое хранит данные в цепочке, имеет нежелательное свойство потребления ресурсов в цепочке, линейно растущее с объемом транзакций свертки. Данные в цепочке включают в себя некоторое состояние (например, детали транзакции) и свидетеля .(например, цифровые подписи, подтверждающие согласие сторон сделки). Разница между OR и StR заключается в том, что OR-свидетель линейно масштабируется с количеством транзакций, тогда как StR заменяет все эти свидетели одним доказательством, которое полилогарифмически масштабируется с количеством транзакций. Важно отметить, что для достаточно больших партий объем данных StR в сети значительно меньше, чем у OR.
Более подробно: в StR свидетель может подтвердить проверки, выполненные оператором свертки (например, все цифровые подписи были проверены), поэтому для каждого пакета вычислений требуется свидетель (например, zk-доказательство), что позволяет избежать необходимости добавить свидетеля к каждой отдельной транзакции. К счастью, в современных zkp-системах доказательство имеет практически фиксированный размер (ну, полилогарифмически, как мы указывали выше). Следовательно, по мере роста партии амортизированная стоимость свидетеля на транзакцию уменьшается.
В OR для каждой транзакции требуется свидетель , чтобы позволить валидаторам гарантировать правильность, поэтому для больших пакетов нет преимущества амортизации. Более того, свидетель в OR значительно больше, чем транзакция: например, свидетель OR должен включать подписи всех пользователей¹, тогда как в VP их можно удалить (поскольку доказательство подтвердит, что они были проверены вне сети). В прозрачных платежах свидетель в 3-5 раз больше, чем сам платеж; в более сложных приложениях (например, экранированных транзакциях) свидетель часто в 10 раз больше, чем состояние, а иногда и больше.
Таким образом, OR потребляет значительно больше сетевых ресурсов и, следовательно, достигнет потолка масштабируемости намного раньше, чем StR.
Общие накладные расходы на вычисления (STARK становятся лучше по мере взросления)
Одно сравнение, часто проводимое между VP и OR, связано с их вычислительными издержками: для того, чтобы данное вычисление выполнялось вне цепочки, сколько дополнительной работы требуется при каждом подходе? Мы сосредоточимся на возможностях StarkWare STARK, так как это инфраструктура VP, которую мы в настоящее время внедряем.
ИЛИ: число, которое часто приводится для ИЛИ, равно 100X, поскольку 100 валидаторов, следящих друг за другом, надеюсь, будет достаточно для обеспечения правильного выполнения вычислений. Для проверки каждый из этих валидаторов должен провести фактические вычисления, следовательно, 100X.
Обратите внимание, что чем меньше/предопределеннее набор валидаторов, тем легче им вступить в сговор или посторонним подкупить/напасть на них.
STARK: Здесь только одна сущность — доказывающая — должна проводить большие вычисления, так как проверка тривиальна с вычислительной точки зрения. Насколько банально? Сегодня можно проверить доказательства для огромных пакетов вычислений с помощью простого смартфона, поэтому мы можем игнорировать затраты на проверку. Число, которое часто приводится для накладных расходов доказывающего, составляет 10 000X, поскольку создание доказательства требует вычислительных ресурсов. Реальность для StR такова, что эти накладные расходы на самом деле примерно в 100 раз больше и, следовательно, находятся на том же уровне, что и для OR. Это всего лишь 100X по нескольким причинам:
- Для арифметических/алгебраических операций у нас уже есть вычислительные накладные расходы менее чем в 100 раз. Хеш-функция Педерсена, которую мы используем в настоящее время, всего в 20 раз дороже, чем собственное вычисление: STARK-доказательство хэша Педерсена в 20 раз медленнее, чем непосредственное вычисление Педерсена.
- Для таких операций, как SHA-256, действительно существуют значительные накладные расходы, но мы намерены заменить эти хеш-функции на STARK-дружественные. Для этого нас профинансировал Ethereum Foundation, и мы ожидаем, что выбранный комитет академических экспертов по криптоанализу выпустит свою рекомендацию в первом квартале 2020 года. Мы ожидаем, что выбранная хэш-функция, дружественная к STARK, будет примерно в 100 раз медленнее, чем эффективный хэш ( например, вычисление SHA-256).
Наконец, один аргумент, который часто приводится в пользу OR, заключается в том, что он применим к общим вычислениям и будет поддерживать код EVM, тогда как VP этого не делает. Мы с оптимизмом смотрим на STARK для общих вычислений.
Спасибо Дэну Робинсону , Джону Адлеру и Виталику Бутерину за комментарии .
¹ BLS часто называют эффективным механизмом агрегации сигнатур. Мы считаем, что BLS не подходит для этого конкретного варианта использования, поскольку он лучше всего подходит для множества подписей в одном сообщении. В случае использования ИЛИ есть много сообщений, которые должны быть подписаны их соответствующим отправителем/получателем; проверка подписей BLS здесь займет около 10 мс на подпись (одна операция сопряжения на сообщение), что обременит как валидаторов (вне цепочки), так и основную цепочку в случае спора о мошенничестве.