PoS: проблемы и перспективы. Часть Вторая: Кроссчейн 2.0
Внимательно изучая последние тенденции, связанные с Tron, Solana, ETH2, можно заметить: большинство прогнозов уже реализовано на практике. Но есть ряд моментов, заметных лишь в числовом обозначении.
Для визуализации хорошо бы представить ряд тестов и выборочных обстоятельств, подлежащих оценки. Но сначала попробуем обсудить несколько важных, общих моментов, от которых зависят перспективы 2023-2025 и даже 2030 года.
*Крайне важно знать, что этот материал написан не как теоретический опус, но как часть серии статей 2019-2022 годов на Bits.media, завершающими из которой стали первая и вторая часть про PoS-семейство.
Эффект Даннинга Крюгера и PoS После того, как основная часть статьи уже была написана, один из чатов Bits.media мне напомнил об этом эффекте. Звучит определение эффекта следующим образом:
«Метакогнитивное искажение у низкоквалифицированных людей: они делают ошибочные выводы и принимают неудачные решения, но не осознают этих ошибок из-за неполноты знаний, умений и навыков, приходя к ложному определению пределов компетенции и завышению представлений о своих способностях — даже в незнакомых областях знаний и впервые совершаемых действиях».
При чем здесь это?
В PoS-семействе с 2013 года подобное происходит постоянно. Пожалуй, самым ярким стоит признать пример Solana, которая несмотря на огромные венчурные вливания и веерный маркетинг — до сих пор работает, по меткому выражению крипто-коммьюнити, «с перерывом на обед». Недавний пример.
Дело в том, что в «солнечном блокчейне» и иных подобных архитектурным проблемам уделяется мало внимания. Причин на то несколько:
Во-первых, при привлечении инвестиций проекты акцентируются на положительных, а не отрицательных сторонах, и в итоге превращается в публичную дорожную карту, которую проект хочет выполнить «во что бы то ни стало», а тем самым — время у проекта на переработку фундаментальных основ не остается. Контрпример — Ethereum и переход на Ethereum 2.0: последовательное признание минусов PoS-семейства дало возможность решить уже на старте ряд проблем. Да, за шесть с лишним лет, зато сразу и в тестовой, и боевой сети: не все, но многие из заявленных.
Во-вторых, компетенции вокруг определенных групп программирования лишь накапливаются: это легко проследить в сравнении solidity-кодеров с RUST/Go, которые только начали путь. А значит? Значит оценить потенциально сложные моменты зачастую просто некому — это как побывать на красной планете впервые: навряд ли Мэтт Дэймон справился также лихо, как его герой из «Марсианина» с представленным набором трудностей. Если думаете, что этот вопрос — сугубо теоретический, рекомендую интервью Александра Скиданова, где он сам, честно и открыто, исходя из понимания рынка, рассказывает о смене стратегии и парадигмы Near. Собственно, если на минуту отойти от PoS-семейства, то проблема окажется наследуема блокчейнами любого уровня и образца: BCH/BSV — яркие примеры.
Зная это — идем дальше.
Сбои vs финализация Если вспомнить базовые принципы архитектуры PoS-семейства, то можно обнаружить, что обычно обсуждаются три параметра, правда, вне связи с друг другом (чаще всего):
TPS как некий, условный, ориентир операционной работы блокчейна.
Финализация, как второй корректирующий параметр.
Децентрализация: точнее — ее уровень (чем выше — тем лучше).
Приведу примеры, чтобы стало яснее:
BSC (BNB chain: о различиях — см. по ссылке): финализация за 33 секунды, но уровень децентрализации супер-узлов страдает при любых подходах (см. пример статистики). С одной стороны — такой подход дает возможность быстрых откатов после взломов и прочих неприятностей, но с другой — мало чем отличается от классических финансов и в итоге играет не на пользу конечных участников.
Polygon: если внимательно изучить все перепетии этой системы (надеюсь, что одна из будущих публикаций будет посвящена как раз этому садчейну — чуть ли не единственному из подсемейства Plasma), — то станет ясно: в итоге 150+ подтверждений зачастую оказывается не достаточно, а это все крайне замедляет dApps и делает работу приложений нестабильной, что особенно ярко видно на примере кроссчейн-мостов.
Harmony: если вам «посчастливилось» разворачивать что-либо на данной системе, особенно через грант, то вы могли заметить: в тестнете многих старых приложений просто нет, а потому — финализация без соотношения с социальным консенсусом мало что дает.
ChatGPT в помощь Но это все — общие аспекты. Попробуем их заапрувить через ChatGPT:
Время финализации: в блокчейнах с алгоритмами консенсуса PoS, DPoS, LPoS и подобных финализация может занимать некоторое время. Что способно привести к задержкам в проведении транзакций и ожиданию подтверждения финализации. В некоторых случаях это неприемлемо для пользователей, которые ждут подтверждения.
Алгоритмы консенсуса могут быть более уязвимы для «атак 51%»: например, в случае DPoS, когда малое количество участников способно контролировать большую часть блокчейна, это может привести к возможности проведения атак 51%. В подобных ситуациях финализация может быть нарушена, что приведет к угрозе безопасности сети. [Прим. Menaskop: тут, конечно, AI дал лиху, потому как больше подошло бы обсуждение атак, оговоренных в первой и второй части исследования, но суть атаки через соединение сибилло-подобных уязвимостей он уловил точно, поэтому оставим как есть].
Возможность отмены транзакций: в некоторых случаях, когда финализация не окончательна, транзакции могут быть отменены. Подобное способно произойти, если кто-то, участвующий в блокчейне, захочет изменить данные, которые уже были записаны. В некоторых случаях это может привести к финансовым потерям или другим проблемам. [Прим. Menaskop: и здесь вновь поправил немного, потому как в предыдущих частях ровно это и обсуждалось].
Недостаток децентрализации: в некоторых алгоритмах консенсуса, таких как PoS, LPoS и других, более крупные держатели криптовалюты имеют большее влияние на решения, принимаемые в блокчейне. Это может привести к недостатку децентрализации и возможному влиянию на процесс финализации транзакций. Если несколько крупных держателей согласятся между собой на отмену определенной транзакции или блока, это может привести к неудачному завершению финализации и созданию потенциальных проблем в блокчейне. [Прим. Menaskop: здесь ИИ вновь смешал сущностное, но оставляю как есть, потому что вектор децентрализации важен для статьи].
Как видите: пришлось немного поправить тезисы ChatGPT, но в целом — они верны. Теперь же попробуем посмотреть на ситуацию со стороны практики и эмпирики.
Примеры и истории Конечно ж, начать стоит с EOS — проекта, на который многие возлагали многие же надежды: в 2018 году в EOS произошел сбой, который как раз и привел к тому, что несколько валидаторов стали обрабатывать один и тот же блок. Что в свою очередь привело к тому, что финализация транзакций была нарушена. Отчет об этом содержится в разных источниках, но оставлю ссылку на данный твит, потому как найти ее на офсайте начальных разработчиков не так-то просто. Теперь.
Можно сослаться на то, что это было лишь при запуске, а можно вспомнить о том, что Qihoo360 за неделю до предупредила крипто-комьюнити, что ошибок значительно больше.
Именно по этой причине раз за разом появляются выводы о том, что EOS — не блокчейн, а «система управления распределенной однородной базой данных, а рынок RAM — сервис облачных вычислений». С другой стороны — именно на этом примере видим, как первичная централизация (о вторичной говорили в первой части) в итоге сказывается на безопасности.
Фактически то, что социальный консенсус не раз становился более мощным инструментом, нежели консенсус технический, как раз и привело DPoS подсемейство Graphene (Bithsares/Steem/Golos/etc.) к упадку.
Нет, причин много, но нас интересуют именно низкоуровневые шаблоны: Tron vs Steem(it), EOS — пример выше, долгий разговор о Golos.io — Golos.id — все это именно противостояние базового технического и социального консенсуса, где последний одерживал верх. Постоянно.
Поэтому соль истории не в том, как интерпретировать ошибку и какие выводы делать из нее, а в том, что эта проблема архитектурного уровня и в эпоху мультичейн она получит развитие. Какое? Поговорим об этом ниже.
А пока — первые цифры. Solana:
Ethereum:
Если сравнивать по TPS, то Solana будет опережать с явным отрывом. Если же провести более полноценную исследовательскую работу, которую мы с вами и делаем, то окажется, что куда важнее:
Учитывать не (только) скорость транзакций и даже не скорость финализации, а именно механизм таковой: если на данный процесс оказывается слишком много влияния — блокчейн будет работать нестабильно.
Крайне значимо посмотреть передачу гипотетического TVL (Total Value Locked) за транзакцию: об этом — см. в следующем абзаце.
Наконец, важно оценить уровень/степень децентрализации: начиная от суперузлов (валидаторы, делегаты, прочие) и заканчивая HODL — владельцами кошельков.
Что касается пункта 2, то имеется ввиду следующее:
Какой TVL у всего DeFi-сегмента на конкретном блокчейне.
Каков процент длинных HODL-волн, то есть тех, кто хранит нативный токен (коин/монету) данного блокчейна три и более года.
Какова медианная доходность MEV-ботов и прочих участников, от них зависящих.
Каковы иные финансовые параметры в момент совершения транзакции.
Опять же, все это может выглядеть избыточным, но крайне помогает на практике.
Приведу пример: если сравнить количество имплементированных смарт-контрактов BSC vs Ethereum, то эфир будет в проигрыше. Визуально, статистически — как угодно. Но если добавить к ним экономические параметры, то выйдет с точностью до наоборот. И проблема эта известна давно: «дешевые, или почти бесплатные транзакции» в архитектуре на самом деле создают две уязвимости на уровне архитектуры:
Демотивируют держателей суперузлов.
Мотивируют создателей скам-токенов и подобных продуктов.
Вывод №01. От технологии к экономике Получаем первый значимый вывод: эпоха технологического аспекта консенсусов не завершена, но прошла первую зрелую стадию, тогда как эпоха экономического аспекта только наступает.
Что это значит?
Во-первых, что за счет все большей интероперабельности, как на уровне L1, так и L2/L3, параметры стабильности будут приоритезированы в сравнении с формальными показателями блокчейнов/DAG-решений.
Во-вторых, рано или поздно придется создать рынок деривативов на технологический стек L1/L2, потому как иначе невозможно полноценное взаимодействие разномастных решений.
В-третьих, суммирование первого и второго тезиса подсказывает: деятельность владельцев суперузлов должна иметь мульти- и кроссчейн-токенизацию, поскольку иначе оплатить положительные эффекты, необходимые для стабильной работы системы, невозможно.
В-четвертых, получаем простую формулу: k = Stable_Work/Security, где Security — безопасность L1/L2 систем, k — коэффициент прямой или обратной зависимости, а Stable_Work — стабильность работы (нормальная работа систем).
Фактически k определяет, как работает система. Скажем:
BSC (BNB chain) близок к формуле 3/1, то есть стабильность работы превышает безопасность;
Bitcoin — это примерно 1/1;
Solana — 1/3.
Чтобы рассчитать параметры точнее — каждый следует обозначить как сумму других параметров в процентах. Примерно так:
1. Пусть Average(Uptime) проходит градацию:
a. 100%-99% = 10%;
b. 98,9%-97% = 3%;
c. Менее 97% = 1%.
2. Далее — отклонение от Average(Finalisation):
a. Менее, чем на 10% = 10%;
b. От 10% до 20% = 3%;
c. Более 20% = 1%.
3. И так далее: параметров может быть 3, 5, 10 или 100 — в зависимости от того, какую точность хотите достичь.
Вес параметра будет считаться так: Parameter_Weight = 100%/Quantity(Parameters). В моем случае параметров — 10, поэтому и максимальный процент для каждого — 10%.
Далее просто складываем: 10%+10%+...10% = 100% или меньше.
В таблице — пример расчета на тестовых и не полных параметрах:
Так же поступаем с безопасностью. Сюда можно отнести следующие показатели:
Количество обновляемых суперузлов.
Количество взломов за год.
Количество форков за год.
Прочие.
Затем получаем, например: 97/30, или 3,2(3). То есть параметр стабильности превалирует над безопасностью, то есть 1 будет идеальным соотношением. Таким образом, можно оценить сразу два архитектурно значимых аспекта:
Абсолютный процент безопасности и стабильности.
Их соотношение.
Можно усложнить формулу и добавить децентрализацию, но рекомендую это делать после первичного анализа стабильности и безопасности.
А зачем это делать вообще? Резонный вопрос. Попробую ответить на него развернуто.
Вывод №02. PoS-семейство на развилке Мы уже видели форки между комьюнити (Hive vs Steem(it), ETH vs ETC, BCH vs BTC, etc), уже наблюдали форки технологического характера (в основном — софт, но бывают и хард, когда дело пахнет керосином, как с Биткоином в 2010 году), но теперь настала эпоха финансово-экономических форков и они будут влиять на слишком многие сферы деятельности, чтобы упускать процесс из виду или не замечать вовсе.
Поясню.
Если кажется, что это теоретическое изыскание, то спешу огорчить: нет, это уже практика. Приведу пример из отчета по экосистеме Cosmos: из-за того, что владельцы суперузлов оценивают экономический аспект перед запуском любого нового проекта, фактически создается искусственная олигополия, где из-за отсутствия первичной (базовой) и общедоступной токенизации работы консенсуса на уровне мультичейн/кроссчейн, она происходит искусственно. Проще говоря: кто первый — того и тапки. Но при этом тапки всегда достаются производителю тапок, хотя логично, что они должны уходить покупателям тапок.
Мне известны по крайней мере два десятка команд, занимающихся валидацией и всем, что с ней связано. Фидбек везде примерно один: если ты — не топ, то прорваться можно или (1) в тяжелые времена (как сейчас), или (2) в силу чистого везения, которое стремится к бесконечно малому значению из-за ангажированности запусков: проекты хотят «проверенные деньги» и проверенных людей, валидаторы — быструю прибыль, в итоге — уровень децентрализации стремится к нулю, а с ним и уровень технологического консенсуса, подменяемого социальным.
Это имеет обратную сторону медали: посмотрите на споры, связанные с разморозкой ETH2, или с выводом средств валидаторов в Solana.
И там, и там мы имеем the bottleneck — бутылочное горлышко первичного распределения: технологический стек не покрывает риски социального из-за начальной централизации, а социальный не может решить технологический в силу того, что команды решают проблемы по мере их поступления, а не на уровне базовой архитектуры. (К слову, переименование ETH2 — еще одно звено этого процесса.)
Что же дальше? Как когда-то PoW, а потом смешанные консенсусы, а за ними и PoS-семейство (что лишь в широком смысле может считаться семейством консенсусов) уперлось сразу в потолок (вертикальное масштабирование), в стены (горизонтальное масштабирование), в пол (масштабирование на уровне базовых элементов экономики-архитектуры).
Это очень легко проследить на примерах, которые взяли «все лучшее» из мира PoW & PoS: Decred, Dash, etc.
И это не значит, что случилось нечто непоправимое, но это точно говорит о том, что эпоха новых систем пришла. Отчасти описанные проблемы будут решены с помощью ZKP-механик, отчасти — детализацией элементов PoS-архитектур, но все же часть останется за инновациями.
И здесь попробую поделиться рядом соображений.
Во-первых, все три части материалов про PoS посвящены ряду проблем, но большая часть из них может суммарно дать одну: централизация ликвидности. Те системы, что смогут решить проблему, на деле и станут передовыми. Проблема, в свою очередь, имеет три элементарных слоя:
Бэкенд (это как раз уровень консенсуса и ниже).
Фронтенд (легко понять на примере Tornado Cash, что шаг в эту сторону сделан).
Мультичейн/кроссчейн интероперабельность.
Вот с последним пока явно никто не работает. Нет, парачейны, сабчейны, хабы, EVM-соместимость и прочее — есть. Но как это решает вопросы совместимости на базовом, архитектурном уровне? Никак. Можно посмотреть снова на пример мостов: да, поколение мостов, создающих обернутые активы, уже позади, и мы в моменте имеем возможность завершения транзакций. Скажем, на allbridge с помощью стандартных стейблкоинов и/или других монет/токенов, а не производных. Но как решается эта проблема? Фактически — через полуавтоматическое завершение транзакций. Следующий шаг — начисление нативной монеты на кошелек-получатель в нужной сети.
А что дальше?
Даже в этом, крайне простом примере, получается следующее:
Транзакция есть в блокчейне №01 (пусть Ethereum).
Транзакция есть в блокчейне №02 (пусть Polygon).
И в том, и в другом есть суперузлы, от которых передаваемая ценность зависит на каждом шаге.
Но итоговая мотивация в двух транзакциях разная:
a) начинает транзакцию №01 клиент моста;
b) продолжает в чейне №01, а потом и №02 — сам мост;
c) а итоговый получатель к транзакции №02 может быть совсем иным лицом и/или тем же, что и отправитель.
Ничего не напоминает?
Если заменим мост набором атомарных свопов, а получателя/отправителя — суперузлами, то получим, что мульти/кроссчейн передача ценности мотивирует кого угодно, но не базовые структуры L1, которые на этом зарабатывают (исходя из внутренней оценки систем, то есть нативными коинами), тогда как все другие — могут и не зарабатывать вовсе.
Парадокс?
Считаю, что да. Но пока системы и так получают новые и новые вливания от неофитов, а потому — этот вопрос или не рассматривается вовсе, или рассматривается на уровне кастомизированных решений (опять же — дальше всех ушли в EVM-подсемействе).
Собственно, в этом и кроется решение для тех проблем, которые Виталик Бутерин обозначил относительно кроссчейна как такового.
Другое дело, что не все технологии еще достигли своего расцвета, чтобы замахнуться на Джомалунгму, а потому есть время для нас, исследователей Web 3.0, нетсталкеров и IT-предпринимателей, чтобы и эту черную дыру закрыть креативом новых подходов.
Пока же у меня все и
До!
PoS: проблемы и перспективы. Часть первая
PoS: проблемы и перспективы. Часть Вторая: Атаки
Источник:
Bits.media
