TL;DR: StarkPay, механизм масштабируемости платежей, основанный на технологии STARK, устраняет многие недостатки Lightning, платежного решения уровня 2.

Первым применением технологии STARK в StarkWare являются механизмы масштабируемости уровня 2. Недавно мы анонсировали StarkDEX , движок масштабируемости для DEX (с некоторыми захватывающими ранними результатами ).

Наш механизм масштабируемости можно использовать для платежей в криптовалюте — мы называем это StarkPay. Появление стейблкоинов удовлетворяет необходимое условие для использования криптовалют в качестве средства обмена. В экосистеме по-прежнему отсутствует масштабируемая платежная система. Мы считаем, что StarkPay может удовлетворить эту потребность.

В этом посте StarkPay сравнивается с Lightning, наиболее известным решением для масштабируемости платежей в биткойнах. Мы начнем с обзора преимуществ и недостатков Lightning, как мы их понимаем. Затем мы опишем базовую архитектуру StarkPay и ее UX. Наконец, мы перечислим преимущества StarkPay, его недостатки и возможные решения с помощью некоторых многообещающих идей, которые мы увидим в будущем.

В этом посте не будут обсуждаться функции конфиденциальности, которые могут быть добавлены в оба решения.

Lightning

Lightning, масштабируемый платежный протокол 2-го уровня, вызвал большой ажиотаж с момента публикации официального документа Poon и Dryja в 2016 году. В настоящее время существует более 3000 узлов Lightning с общей заблокированной стоимостью более 2 миллионов долларов. Lightning Torch стоит более 100 долларов, и его используют титаны высоких технологий, такие как Джек Дорси и Рид Хоффман , и финансовые гиганты, такие как Fidelity .

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

Молния также имеет несколько недостатков. Давайте рассмотрим некоторые из них:

Требование : для совершения платежа плательщик должен быть онлайн — в этом нет ничего удивительного. Но в Lightning — в отличие от Биткойна — получатель платежа также должен быть в сети, чтобы подписать транзакцию своим закрытым ключом (подробнее о соображениях безопасности операций позже). Что еще хуже, с этого момента Получатель должен следить за блокчейном, чтобы убедиться, что Плательщик не отправляет устаревшее состояние своего баланса и не закрывает канал. Узлы маршрутизации также должны быть подключены к сети между тайм-аутами восходящего и нисходящего каналов, чтобы участвовать в протоколе (т. е. пересылать прообраз) до истечения срока действия восходящего HTLC.

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

Неэффективность капитала:Как правило, в обмен на удобство Payers готовы заблокировать капитал — подумайте, например, о дебетовых картах. Но в Lightning капитал должен быть заблокирован для каждого канала, а не только для каждого плательщика.

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

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

Что, если мы хотим избежать таких централизованных сетей? Чем больше хмеля, тем выше стоимость капитала — поскольку это заблокированный капитал, а не приносящий процент в другом месте. Например, если Алиса хочет отправить Бобу 1 монету через 5 узлов маршрутизации, для этого потребуется заблокировать 5 монет в сети Lightning. Эти затраты (и дополнительные затраты на грифинг-атаки, когда узлы маршрутизации перестают сотрудничать) должны будут переводиться в комиссионные, которые несут транзакторы; отсутствие таких сборов сегодня можно объяснить альтруистическим поведением первых последователей Lightning.

Мотивация к снижению неэффективности капитала является силой централизации в экосистеме Lightning. Очевидно, интерес представляет степень централизации Lightning .

Проблема безопасности операций. В адрес централизованных бирж часто можно услышать критику за то, что они создают приманки для криптовалют, привлекающие хакеров. В масштабе узлы маршрутизации в сетях Lightning создадут гораздо более заманчивую приманку. Подумайте о раскрытии закрытого ключа в горячем кошельке: централизованные биржи должны быть раскрыты только на короткое время, в то время, которое они выбирают. Узлы маршрутизации, с другой стороны, должны обеспечивать практически мгновенный сервис, поэтому они будут доступны в любое время. А чтобы приносить пользу, им нужно иметь достаточный капитал (на канал!). У него есть задатки идеальной приманки: много капитала и закрытый ключ поблизости. Защита этого горшка с медом приведет к расходам, которые, скорее всего, покроются сборами.

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

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

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

[Примечание: для простоты мы предполагаем, что маршрутизация Lightning полностью решена бесплатно. Конечно, есть те, кто думает, что это сложная проблема ]

А теперь совсем о другом (M. Python)

StarkPay

StarkPay стремится предложить масштабируемое платежное решение, не связанное с хранением, с эффективным использованием капитала, без требований к жизнеспособности.

Строительные блоки

StarkPay включает в себя строительные блоки вне сети и внутри сети.

Вне сети

• Платежный процессор, который взаимодействует с плательщиками и получателями.
• Дерево балансов плательщиков: они обновляются доказывающим, и их доступность обеспечивается (см. дальнейшее обсуждение ниже).
• Доказательство, которое создает доказательства STARK, подтверждающие достоверность пакетов платежей, предоставленных обработчиком платежей, и достоверность обновления балансов Плательщиков.

В сети

• Платежный контракт, который является входным/выходным для StarkPay, а также хранит обязательство по обновленным балансам плательщиков (хранящимся вне сети, как упоминалось выше).
• Контракт верификатора, который проверяет доказательства, сгенерированные проверяющим, и взаимодействует с платежным контрактом.

Давайте рассмотрим несколько основных сценариев:

Депозит («Наращивание»)

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

Снятие («отключение»)

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

Алиса платит Бобу

• Алиса подписывает (она никогда не отказывалась от опекунства!) свой платеж Бобу и отправляет его процессору платежей.
• Платежный процессор отправляет пакет платежей, включая платеж Алисы, доказывающему.
• Prover создает доказательство STARK, подтверждающее действительность платежей в пакете и действительность обновления балансов: он проверяет цифровые подписи и подтверждает, что у плательщика достаточно средств, а затем обновляет обязательство по балансам (например, корень Меркла).
• Доказывающий отправляет доказательство и новое обязательство по контракту с верификатором по цепочке. Как только доказательство проверено, верификатор отправляет платежному контракту новое обязательство, которое он хранит в хранилище в цепочке (как указано выше).

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

Преимущества

Мы считаем, что эта системная архитектура обеспечивает предполагаемые преимущества:

Масштабируемость: вычислительные ресурсы, потребляемые StarkPay, масштабируются в зависимости от количества плательщиков и количества совершенных платежей. Важно отметить, что они не масштабируются с общей стоимостью транзакций. Мы уже в шаге от интересного масштаба: StarkPay сможет поддерживать более 10 000 платежей в одном блоке в соответствии с текущими ограничениями газа Ethereum.

Примечательно, что STARK потребляют чрезвычайно скудные вычислительные ресурсы в сети с умеренностью: они растут логарифмически с размером вычислений вне сети. Приведем числовой пример: чтобы увеличить StarkPay в 10 раз, потребление вычислительных ресурсов в сети вырастет менее чем на 50%.

Обратите внимание, что при наблюдении за потенциально интересной концепцией, такой как стоимость в секунду, а не только транзакции в секунду, StarkPay практически не имеет ограничений.

Эффективность капитала: как и в метафоре с дебетовой картой, не нужно блокировать дополнительный капитал, кроме средств, которые каждый плательщик желает заплатить. В частности, Платежный процессор и Доказывающий не имеют требований к ликвидности.

Liveness-free : обновление баланса Получателя не требует, чтобы он был в сети. Во всех сценариях (депозит, снятие средств и оплата) транзакция может быть выполнена в автономном режиме, а затем отправлена ​​​​в блок-цепь\обработчик платежей.

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

В этом отношении StarkPay соответствует собственности Lightning, так как и здесь пользователь сохраняет за собой хранение криптовалюты.

Недостатки

StarkPay имеет несколько заметных недостатков:

Доступность данных. Чтобы по-настоящему извлечь выгоду из логарифмического масштабирования STARK в сети, данные лучше всего хранить вне сети, что создает проблему доступности данных. Доступность данных — это проблема, которую должны решить решения на основе Plasma, чтобы оставаться свободными от доверия и при этом преодолевать потолок масштабируемости.

Смягчение :

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

Централизация : изначально пруверы будут управляться StarkWare. Это представляет риск централизации и, как следствие, цензуры.

Смягчение :

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

Задержка : в отличие от мгновенного расчета, гарантированного в одноранговом канале Lightning, время, необходимое для создания доказательств для больших пакетов, в настоящее время составляет порядка минут.

Смягчение :

• Доказывающий может предоставить обязательство по платежному контракту сразу после проверки пакета полученных платежей при создании доказательства. Риск, на который идет Получатель платежа — опять же, риск, который длится несколько минут, — заключается в том, что Доказывающий будет удерживать доказательство на неопределенный срок. Этот риск можно компенсировать, например, наличием средств Prover. Стоит отметить: достигнутая задержка будет такой же, как у основной цепи, а не почти мгновенной задержкой Lightning.
  Как всегда, задержку не следует приравнивать к пропускной способности: StarkPay может обеспечить более высокую пропускную способность за счет увеличения вычислительных ресурсов Prover, которые все находятся вне сети.

Биткойн-решение отсутствует : Биткойн в его нынешнем виде не может поддерживать эффективный верификатор STARK, работающий в сети.

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

В этом посте мы представили StarkPay, механизм масштабируемости на основе STARK для платежей в криптовалюте. Мы начали с анализа Lightning, популярного решения масштабируемости для биткойнов, и сравнили его со StarkPay. Мы пришли к выводу, что StarkPay предлагает привлекательную альтернативу, которая превосходит Lightning по нескольким важным параметрам.

Спасибо Виталику Бутерину, Патрику МакКорри, Джиму Позену и Дэну Робинсону за комментарии к черновикам этой публикации.

Том Брэнд, Ури Колодный и Авиху Леви