Токенизация платёжных каналов и роллапов. NIFTSY

Дисклеймер - пожалуй, в этот раз стоит вас предупредить: материал имеет ряд упрощений и допущений, каждое из которых требует отдельного и весьма детального разбора. Но как бы там ни было - нам, команде (фаундерам, эдвайзерам и активным членам комьюнити), нужно обрисовать границы архитектуры супер-ДАО NIFTSY (Protocol + Oracle + Index + Token), чтобы потом уже приближать на нужный ракурс и объяснять конкретные элементы. Поэтому будьте готовы к захватывающему, но весьма не простому приключению!

Каналы и роллапы - в чём отличие для нас?

Давайте сначала посмотрим на то, что есть в принципе:

https://lightning.network - “платёжный протокол, оперирующий над блокчейнами (обычно используется Биткоин). Позволяет проводить моментальные транзакции между участвующими нодами и предлагается как решение проблемы масштабируемости”. Статистику можно посмотреть ниже (впрочем, взяли усреднённый вариант: скажем, максимальный показатель, предоставляемый сервисом https://1ml.com, равен 24 085 нод): с учётом того, что концепт родился в 2015-2016 гг. и был реализован в 2016-2017 гг. (если, конечно, не углубляться: общий посыл был сформулирован ещё в 2009-201... гг. и его можно найти, скажем, у Сатоши) - рост вполне перспективен на рубеже будущих 5-10 лет. Также для более глубинного понимания рекомендуем изучить следующие параметры: рост числа заблокированных монет (BTC в частности), рост числа открытых каналов, пропускную способность каналов. Если не хотите сегодня - ждите следующий материал с разбором цифр.
https://plasma.io/plasma.pdf - сеть Lightning для Ethereum, а если ещё точнее, то “Plasma состоит из двух ключевых частей проекта: пересмотр всех вычислений блокчейна в набор функций MapReduce, и необязательного метода привязывания токена Proof-of-Stake”. Крайне важно отметить, что связь между малыми цепочками и основной цепью защищена fraud-proof, поэтому основная цепь отвечает за безопасность, а значит и своеобразное отсечение злоумышленников (через наказание). Whitepaper Плазмы как раз и представляет интересное применение так называемых вычислений MapReduce – набор функций, которые очень полезны для организации и вычисления данных в нескольких баз данных, но в контексте Плазмы, эти базы данных являются блокчейнами, а “древовидная структура цепочек позволяет применять MapReduce, как способ облегчения проверки данных внутри цепочек древа, что значительно повышает эффективность сети”. Подробности можно изучить по ссылке №01 и по ссылке №02.
https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/ - если же говорить о роллапах, то Optimistic & ZK-роллапы - must have для изучения. В том числе - можно сразу обратиться к их сравнению. Роллапы - это “решения, которые выполняют транзакции вне основной цепочки Ethereum (уровень 1), но размещают данные о транзакциях на уровне 1. Поскольку данные транзакции находятся на уровне 1, это позволяет роллапам быть защищёнными на уровне 1. Наследование свойств безопасности первого уровня при выполнении транзакций вне первого уровня является определяющей характеристикой роллапов. Роллапы требуют, чтобы "операторы" вносили залог в контракт роллапа. Это стимулирует операторов к проверке и правильному выполнению транзакций”.

Для тех, кто захочет углубить, несколько примеров по п. 3:

Но прежде, чем продолжить, - ещё раз посмотрим на статистику:

Трудности. Переводов

Один умный человек как-то решил собрать все плюсы и минусы Эфира постом и сделал это: https://twitter.com/RyanSAdams/status/1344461378921365506. Но с тех пор много вопросов родилось сверху.

Один из них, который должен задать каждый, кто погружается в проблематику каналов, звучит просто: “а зачем нужны каналы, если ETH2 - уже PoS?”. И действительно: зачем? Скорость и так будет приличная, вопросы масштабирования за счёт шардинга (просто пока допустим это и примем как свершившийся, пусть и якобы, факт) можно будет тоже устранить…

И зачем тогда всё это?

На этот вопрос можно ответить так: “дело в двух аспектах: во-первых, каналы можно токенизировать; во-вторых, они, как и роллапы, дают возможность делать надстройки вне основной сети и тем самым кастомизируют запросы бизнеса и/или пользователя”.

Давайте попробуем п(р)ояснить эти два аспекта.

Возьмём MEV - “показатель прибыли, которую майнер (или валидатор, секвенсор и др.) может получить за счёт своей способности включать, исключать или изменять порядок транзакций по своему усмотрению в создаваемых ими блоках”. А значит? Значит, если мы хотим минимизировать риски от различных атак внутри сети, мы должны… из этой сети выйти. Но как тогда использовать преимущества ДРС (децентрализованных и/или распределённых систем)? Самый простой способ - создать свой канал (роллап) и внутри него взаимодействовать с другими бизнесами, а равно и потребителями, сводя к минимуму атаки от различных Супер Узлов.

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

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

Если захотите окунуться в мир ZK глубже, то Wiki будет не достаточно, а потому - вот вам набор, с которого можно начать:

zk-SNARKs во всей своей красе:

Bulletproofs протокол: http://web.stanford.edu/~buenz/pubs/bulletproofs.pdf
ZK против (пост) квантовой криптографии (и в ней): https://eprint.iacr.org/2018/046.pdf

Теперь коротко то, чем же занимается NIFTSY в аспекте токенизации платёжных каналов и роллапов.

NIFTSY, или новый уровень

Первое - на Optimistic, скажем, перешли Uniswap & 1inch (и не только они), но пока эти решения используются лишь для оптимизации транзакционных издержек для самого проекта и его участника. Как быть с главной целью всех DAODEX, в том числе - DeFi, проектов - с ликвидностью? Она ведь остаётся запертой.

Тут-то и приходит на помощь токенизация:

Создаём канал (роллап).
В нём есть неснижаемый порог ликвидности вносимой (больше можно - меньше нельзя): всё как с накопителем в NFT.
Имитируем NFT на данную (минимальную) ликвидность и выносим этот актив во вне.
Можно торговать внутри канала (до закрытия) и NFT, который с ним связан.

Очевидно возникают вопросы безопасности: прежде всего - связки рабочего канала и NFT. Данная проблема решается на трёх уровнях:

Организационный: администратором канала становится одно из микро-ДАО NFT и контролирует процесс открытия/закрытия/блокировки.
Технический: уничтожить NFT и/или обнулить накопитель можно лишь перед закрытием канала, тогда как канал закрыть без “уничтожения” (сжигание/заморозка) NFT канал закрыть невозможно: это способ защиты - обратный тому, что имеем сегодня. То есть сегодня у вас есть уникальный ID-ключ (приватный) и пока им владеете - можно подтвердить вход, доступ и что угодно ещё. Тут же только уничтожение ключа может инициировать закрытие канала: но закрытие не обязательно, а лишь возможно.
Экономический: поставщикам ликвидности более выгодно торговать двумя финансовыми инструментами, а не одним.

Схематично это выглядит так:

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

Важные источники

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

Конечно же, данная документация не является исчерпывающей или даже общепризнанной, но она точно поможет техническим и, что важно, не техническим специалистам изучить вопрос и шире (по направлениям интеграции) и глубже (относительно механики внедрения через Протокол/Оракул NIFTSY):

2013:

2014:

2015:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

2016:

2018:

https://github.com/ElementsProject/lightning

2020:

2021:

https://ethereum.org/en/developers/docs/scaling/layer-2-rollups/

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

Вводная часть: https://forklog.com/chto-takoe-lightning-network-rukovodstvo-dlya-nachinayushhih/
Предпосылки: https://forklog.com/predposylki-sozdaniya-lightning-network-i-sravnitelnyj-analiz-s-drugimi-platezhnymi-sistemami/
Области применения: https://forklog.com/oblasti-primeneniya-lightning-network-opisanie-tehnologii-i-primery-ispolzovaniya-v-razlichnyh-oblastyah/
Смарты: https://forklog.com/smart-kontrakty-v-seti-lightning-network-tehnicheskoe-opisanie-kontseptsii/
Способы применения: https://forklog.com/platezhnyj-kanal-v-lightning-network-sposoby-ego-primeneniya-dlya-bystrogo-obmena-bitkoinami/
Масштбаирование: https://forklog.com/lightning-network-reshenie-problemy-masshtabirovaniya/

Что будет дальше?

А дальше попробуем рассмотреть простые вопросы, которые как-то опубликовали наши коллеги:

Как узлы находят друг друга и обмениваются информацией о топологии сети (discovery)?
Как достигается анонимность (onion routing)?
Как шифруется передача данных между узлами (brontide)?
Как не скачивать весь блокчейн для полноценной работы узла (neutrino)?
Какова структура инвойса (payment-encoding)?
Как сжато хранить ключи для аннуляции состояния (shachain, elkrem)?
Какие алгоритмы используются для поиска пути платежа (routing)?

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

Все вопросы пишите смело в группу: https://t.me/niftsy и

До!