Для визуализации хорошо бы представить ряд тестов и выборочных обстоятельств, подлежащих оценки. Но сначала попробуем обсудить несколько важных, общих моментов, от которых зависят перспективы 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-семейства, то можно обнаружить, что обычно обсуждаются три параметра, правда, вне связи с друг другом (чаще всего):

1. TPS как некий, условный, ориентир операционной работы блокчейна.

2. Финализация, как второй корректирующий параметр.

3. Децентрализация: точнее — ее уровень (чем выше — тем лучше).

Приведу примеры, чтобы стало яснее:

1. BSC (BNB chain: о различиях — см. по ссылке): финализация за 33 секунды, но уровень децентрализации супер-узлов страдает при любых подходах (см. пример статистики). С одной стороны — такой подход дает возможность быстрых откатов после взломов и прочих неприятностей, но с другой — мало чем отличается от классических финансов и в итоге играет не на пользу конечных участников.

2. Polygon: если внимательно изучить все перепетии этой системы (надеюсь, что одна из будущих публикаций будет посвящена как раз этому садчейну — чуть ли не единственному из подсемейства Plasma), — то станет ясно: в итоге 150+ подтверждений зачастую оказывается не достаточно, а это все крайне замедляет dApps и делает работу приложений нестабильной, что особенно ярко видно на примере кроссчейн-мостов.

3. Harmony: если вам «посчастливилось» разворачивать что-либо на данной системе, особенно через грант, то вы могли заметить: в тестнете многих старых приложений просто нет, а потому — финализация без соотношения с социальным консенсусом мало что дает.

ChatGPT в помощь

Но это все — общие аспекты. Попробуем их заапрувить через ChatGPT:

1. Время финализации: в блокчейнах с алгоритмами консенсуса PoS, DPoS, LPoS и подобных финализация может занимать некоторое время. Что способно привести к задержкам в проведении транзакций и ожиданию подтверждения финализации. В некоторых случаях это неприемлемо для пользователей, которые ждут подтверждения.

2. Алгоритмы консенсуса могут быть более уязвимы для «атак 51%»: например, в случае DPoS, когда малое количество участников способно контролировать большую часть блокчейна, это может привести к возможности проведения атак 51%. В подобных ситуациях финализация может быть нарушена, что приведет к угрозе безопасности сети. [Прим. Menaskop: тут, конечно, AI дал лиху, потому как больше подошло бы обсуждение атак, оговоренных в первой и второй части исследования, но суть атаки через соединение сибилло-подобных уязвимостей он уловил точно, поэтому оставим как есть].

3. Возможность отмены транзакций: в некоторых случаях, когда финализация не окончательна, транзакции могут быть отменены. Подобное способно произойти, если кто-то, участвующий в блокчейне, захочет изменить данные, которые уже были записаны. В некоторых случаях это может привести к финансовым потерям или другим проблемам. [Прим. Menaskop: и здесь вновь поправил немного, потому как в предыдущих частях ровно это и обсуждалось].

4. Недостаток децентрализации: в некоторых алгоритмах консенсуса, таких как 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 будет опережать с явным отрывом. Если же провести более полноценную исследовательскую работу, которую мы с вами и делаем, то окажется, что куда важнее:

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

2. Крайне значимо посмотреть передачу гипотетического TVL (Total Value Locked) за транзакцию: об этом — см. в следующем абзаце.

3. Наконец, важно оценить уровень/степень децентрализации: начиная от суперузлов (валидаторы, делегаты, прочие) и заканчивая HODL — владельцами кошельков.

Что касается пункта 2, то имеется ввиду следующее:

1. Какой TVL у всего DeFi-сегмента на конкретном блокчейне.

2. Каков процент длинных HODL-волн, то есть тех, кто хранит нативный токен (коин/монету) данного блокчейна три и более года.

3. Какова медианная доходность MEV-ботов и прочих участников, от них зависящих.

4. Каковы иные финансовые параметры в момент совершения транзакции.

Опять же, все это может выглядеть избыточным, но крайне помогает на практике.

Приведу пример: если сравнить количество имплементированных смарт-контрактов BSC vs Ethereum, то эфир будет в проигрыше. Визуально, статистически — как угодно. Но если добавить к ним экономические параметры, то выйдет с точностью до наоборот. И проблема эта известна давно: «дешевые, или почти бесплатные транзакции» в архитектуре на самом деле создают две уязвимости на уровне архитектуры:

1. Демотивируют держателей суперузлов.

2. Мотивируют создателей скам-токенов и подобных продуктов.

Вывод №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% или меньше.

В таблице — пример расчета на тестовых и не полных параметрах:

Так же поступаем с безопасностью. Сюда можно отнести следующие показатели:

1. Количество обновляемых суперузлов.

2. Количество взломов за год.

3. Количество форков за год.

4. Прочие.

Затем получаем, например: 97/30, или 3,2(3). То есть параметр стабильности превалирует над безопасностью, то есть 1 будет идеальным соотношением. Таким образом, можно оценить сразу два архитектурно значимых аспекта:

1. Абсолютный процент безопасности и стабильности.

2. Их соотношение.

Можно усложнить формулу и добавить децентрализацию, но рекомендую это делать после первичного анализа стабильности и безопасности.

А зачем это делать вообще? Резонный вопрос. Попробую ответить на него развернуто.

Вывод №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 посвящены ряду проблем, но большая часть из них может суммарно дать одну: централизация ликвидности. Те системы, что смогут решить проблему, на деле и станут передовыми. Проблема, в свою очередь, имеет три элементарных слоя:

1. Бэкенд (это как раз уровень консенсуса и ниже).

2. Фронтенд (легко понять на примере Tornado Cash, что шаг в эту сторону сделан).

3. Мультичейн/кроссчейн интероперабельность.

Вот с последним пока явно никто не работает. Нет, парачейны, сабчейны, хабы, EVM-соместимость и прочее — есть. Но как это решает вопросы совместимости на базовом, архитектурном уровне? Никак.
Можно посмотреть снова на пример мостов: да, поколение мостов, создающих обернутые активы, уже позади, и мы в моменте имеем возможность завершения транзакций. Скажем, на allbridge с помощью стандартных стейблкоинов и/или других монет/токенов, а не производных. Но как решается эта проблема? Фактически — через полуавтоматическое завершение транзакций. Следующий шаг — начисление нативной монеты на кошелек-получатель в нужной сети.

А что дальше?

Даже в этом, крайне простом примере, получается следующее:

1. Транзакция есть в блокчейне №01 (пусть Ethereum).

2. Транзакция есть в блокчейне №02 (пусть Polygon).

3. И в том, и в другом есть суперузлы, от которых передаваемая ценность зависит на каждом шаге.

4. Но итоговая мотивация в двух транзакциях разная:

       a) начинает транзакцию №01 клиент моста;

       b) продолжает в чейне №01, а потом и №02 — сам мост;

       c) а итоговый получатель к транзакции №02 может быть совсем иным лицом и/или тем же, что и отправитель.

Ничего не напоминает?

Если заменим мост набором атомарных свопов, а получателя/отправителя — суперузлами, то получим, что мульти/кроссчейн передача ценности мотивирует кого угодно, но не базовые структуры L1, которые на этом зарабатывают (исходя из внутренней оценки систем, то есть нативными коинами), тогда как все другие — могут и не зарабатывать вовсе.

Парадокс?

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

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

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

Пока же у меня все и

До!

PoS: проблемы и перспективы. Часть первая

PoS: проблемы и перспективы. Часть Вторая: Атаки