Грозолушка

Ламер откладывает один длиннопост ради разбора 4х статей (суммарно 250 страниц высшей математики, логики и теории множеств, три десятка теорем и пара десятков лемм, следствий и доказательств), разбирается с типами консенсусов, узнаёт в чем реальный гений Накомото, а также рассказывает о простом и гениальном решении двух учёных из проекта Thunder Token.

by CryptoLamer

Вместо эпиграфа

-Ламер, может тебе перключиться стоит? Раз про Тандерминт не получается.

-Пожалуй! Есть предложения?

-Да, ThunderToken!

-A что там?

-4 статьи высшей математики, по 70 листов каждая!

Илья Ефимович Репин “Портрет КриптоЛамера за работой” 1884 год

Оуоуоу….ножи убрали….знаю, что три недели не писал. Тандерминт будет и он будет очень крутым произведением, но когда точно я хз.

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

Проблема

Теорема: У любой проблемы есть решение

Доказательство: Ну а как ты объяснишь вот это тогда? https://youtu.be/PidPKIdRARA

 

Собственно, гениальность Сатоши, как я тут узнал буквально вчера, не в изобретении биткойна. Ну а в чём же, спросишь ты меня, мой мамкин владелец криптофонда на 8лямов баксов? А я тебе отвечу!

Проблема переноса данных между узлами сети без потери текущего состояния при полном согласии между ними с тем, что у каждого узла текущее состояние отображается правильно, появилась лет так 30 назад. Сейчас, находясь в крипте, мы это знаем с тобой по кодовым фразам в вайтпейперах типа State Machine Replication (буквально “перенос состояния конечного автомата”) или Linearly Oredered Log (“Линейно упорядоченный список” или LOL:)) . А в простонародии это называется….барабанная дробь… Консенсус

Нет-нет-нет, моя любимая блонди-редактор, сейчас ты всё сама поймёшь!

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

1. Consistancy – согласованность. Все честные узлы сети согласны с текущим LOL.
2. Liveness – живучесть. Это свойство означает, что все транзакции в сети буду включены в LOL всех честных нод.

Протоколы консенсуса были известны ещё с конца 80х. И они прекрасно работают до сих пор во многих распределённых централизованных системах. Такие протоколы прекрасно работают там, где:

• сеть организована внутри одной организации
• количество узлов в сети не превышает пары десятков
• скорость передачи в данной локальной сети очень высокая
• не хранится ни одного трека рэпера фэйса (но это не точно)

Такие протоколы типа PAXOS и его аналогов, а также PBFT-образных протоколов очень любят в кремниевой долине. На таких протоколах построен, например, сервис Apache Zookeeper, который используется в организациях типа Yahoo, Uber, Reddit и т.п. За счёт древности данных решений и проверенности методов применения их называют Классическими, как Светлая Золотая Корона (кто про что, а Ламер про пиво! – прим. блонди-редактора).

Применение таких протоколов в данных организациях полностью оправдано. Но что, если мы говорим о сетях в миллионы миллионов узлов по всей планете? Можно ли применить данные алгоритмы консенсуса к таким сетям?

Проблема таких протоколов в их организации. Сети, построенные на таких протоколах можно визуально изобразить так:

Классические протоколы

Верхная часть рисунка – классическая Voting System c лидером в центре. Лидер подписывает транзакции, попадающие в сеть, и передает их на голосование, кворум или комитет голосует за транзакцию. Если транзакция набрала 3/4 голосов, то она считается валидной. При позитивном сценарии, такая сеть обеспечивает крайне высокую скорость транзакций, в виду того, что алгоритм асинхронен (любой узел голосует за любую транзакцию в любое время) и отличные показатели согласованности и живучести при позитивном развитии событий, т.е. когда сеть работает в штатном режиме. Позитивных случаев в сетях с классическими протоколами консенсуса 99%. Но, когда наступает тот самый 1% 3,14здеца, то в игру вступает вторая половина алгоритма – комплексный механизм под названием Recovery path. Он настолько сложен и запутаннен, что занимает примерно 99% кода протокола. Есть такой стартап chain.com. Так вот, работая по классическому алгоритму консенсуса ребятам приходится восстанавливать сеть после сбоя вручную!!! Поэтому, свойство живучести у сетей, построенных на такой парадигме, крайне тяжело выполнить в случае пессимистичного развития событий. Основные причины 3,14здеца – лидер скомпрометирован или оффлайн, более 1/4 нод скомпрометировано или оффлайн.

Вот здесь и проявился гений Накомото. Своим достаточно простым механизмом Накомото смог классические алгоритмы заменить на новые, на основе бездоверительной цепочки блоков. Тем самым, позволив достигать консенсуса миллионам узлов одновременно, при этом обеспечивая свойства согласованности и живучести. Главная фишка консенсусов Накомото – это обеспечение свойства живучести сети, при возникновении пессимистичных вариантов развития событий. Так сказать, спасительная соломка под названием “вычислительная мощность”. Энергозатратный механизм – ценный ресурс консенсуса, которым делиться не очень выгодно. Но у консенсуса Накомото есть один существенный недостаток. Он крайне медленный. Причина в его синхронности, все ноды в цепи должны одновременно получить информацию о создании в сети нового блока. Поэтому, интервал между блоками должен быть в 60 раз больше, чем максимальная задержка в сети, иначе появляются блоки-сироты, заторы или bottlenecks.

Таким образом, мы имеем быстрые классические алгоритмы консенсуса, которые имеют прекрасные скоростные характеристики, но не обеспечивают свойства живучести при различных проблемах сети. И есть блокчейн-алгоритмы консенсуса, которые обеспечивают оба главных свойства State machine replication, но крайне медлительны из-за свой синхронной природы. И тут возникает вопрос.

Что делать?

Теорема два: Позитивным легче жить.

Доказательство: от Бориса Моисеева (от противного) – А что, есть что возразить? Есть? Ну и чо? 

Двое американских учёных: гениальный молодой парень Рафаэль Пасс и американка китайского происхождения Элейн Ши, посветили проблемам консенсусов целый ряд научных работ. И вот, когда они вычленили проблемы, которые я описал выше – они пришли к очень простому и одновременно гениальному решению.

Блокчейн с оптимистичным мгновенным подтверждением!

Блокчейн с оптимистичным мгновенным подтверждением – есть одновременное решение проблем классических и блокчейн-консенсусов Накомото. Он объединяет в себе две парадигмы (ого! какое слово выучил), убирая все недостатки классических протоколов и решая одновременно проблему скорости транзакций в блокчейн-консенсусах. Визуально это выглядит так

Блокчейн  с оптимистичным мгновенным подтверждением

Всё гениальное просто! Не так ли? Вот и здесь, взяли классический протокол, выкинули из него сложный и запутанный Recovery Path и заменили на обычный Blockchain. Ну а далее, просто на протяжении 20 теорем и 10 лемм!

Пасс и Ши математически доказывают работоспособность своего проекта для permissoined (читай под контролем организаций) и permissioneless (публичных, открытых любому) сетей и  и фактическое обеспечение двух основных свойств консенсусов.

Ну и название у данного проекта соответствующее – Thunderella. Быстрый, как гроза и вырвавшийся из подвала на бал, как Золушка, Накомото. Ну или визуализация в русском переводе:

и в номинации “Я фотошоплю как кретин” побеждает…

Пасс и Ши исходят из положения, что в 99% случаях сценарий работы сетей оптимистичный. Что подтверждается практикой. А значит, не нужно заморачиваться со всякими 51%, свойствами и прочим. Есть лидер, он не скомпрометирован, есть комитет, 3/4 из которого честны и находятся онлайн. И всё. Практически мгновенное подтверждение транзакций гарантировано! Асинхронный подход применим практически для любого количества нод и обеспечивает шикарную скорость транзакций. Ну а если в игру вступает тот самый 1%, то вместо сложного механизма восстановления работает медленный, но живучий блокчейн. Как?

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

Но краткую суть я донесу. Итак, лидер жульничает, кворума нет! Половина узлов в оффлайне забухало, вторая половина – это Артур Роуз (нет, не порноактёр, кто знает, тот поймёт!). Короче, вот он пессиместичный сценарий во всей своей красе наступил. Что же происходит?

Все читерские транзакции и действия из верхнего быстрого слоя, или как его называют авторы, “Fast Chain”, регистрируются в медленном нижнем слое или в “Slow chain”. Майнеры slow chain могут видеть, как в fast chain появились транзакции, не собирающие достаточно голосов. И такая бадяга длится на протяжении вот уже N блоков, где N – это некий параметр безопасности. Это означает, что в быстрой цепочке что-то не так. Тогда майнеры могут запустить контракт, который позволяет восстановить работоспособность быстрой цепочки. При этом подтверждение транзакций также ложится на slow chain. Не быстро, но, в отличие от Recovery Pass, свойство живучести полностью выполняется! Сеть продолжает работать, перебоев, как в случае с классическими протоколами, не происходит.

Однако, возникает ещё одна проблема. При возникновении проблем в Fast Chain, у каждой ноды своя собственная цепочка может отличаться по длине. Например, потому что,  кому какое количество транзакций отправил скомпрометированный лидер точно неизвестно. Поэтому, необходимо понять в какой момент что испортилось и на каком блоке необходимо произвести CutOff или, по нашим древним еврейским традициям, обрезание цепи. Как же решить данную проблему и определить момент обрезания? Здесь опять на помощь приходит медленный синхронный блокчейн. Что же происходит конкретно, расписываю по шагам, чтобы даже блондинки понимали:

1. Прекращается участие всех узлов в поддержке Fast Chain.
2. Все узлы сообщают друг другу что они знают, по-любимому нами со времен Хэшграфа протоколу сарафанного радио или Gossip Protocol.
3. Данные всех узлов отправляются в блокчейн slow chain.
4. В slow chain устанавливается волшебная штука под названием Grace Period или переходный период длинной K блоков ( K – ещё один параметр безопасности, для вычисления которого в данный конкретный момент также есть свой алгоритм)
5. На протяжении Grace Period, slow chain устанавливает ту самую длину цепи, на которой необходимо произвести обрезание и запустить процесс восстановления Fast Chain. Ясно, что максимальная длина Cut Off цепи не будет короче длины цепи любой другой ноды, т.е. по факту, CutOff – самая короткая валидная цепь из Fast Chain.

Всё ясно, просто и гениально.

Слушай, ну даже теоремами и леммами не стал тебя мучить и их доказательствами.

Есть ли у меня к данному решению вопросы? Безусловно. Как решается проблема безопасности консенсуса Накомото в Slow Chain? Как будут избираться лидер и комитет в Fast Chain? Как происходит запись из асинхронной части в синхронную? Может ли Slow Chain инициировать ложную тревогу и как от этого защититься? Почему в команде нет Вадима Казаченко? А то мне кажется мы стали забывать автора великого хита “белая метелица”. т.е. ещё очень и очень многое придётся обсудить.

Итог

Проект Thunder Token предлагает объединить в своём протоколе Thunderella лучшие моменты классических консенсусных протоколов и Блокчейн-протоколов Накомото, тем самым нивелируя недостатки каждого. В вайтпейпере проекта на протяжении 20 теорем и 10 лемм доказывается работоспособность и защищённость этой новой парадигмы протоколов. Причём, работоспособность такого типа протоколов доказана Ши и Пассом и для публичных permissionless сетей, и для приватных permissioned сетей. Чем, собственно, проект крайне взбудоражил струны души твоего покорного Ламера. Ещё раз, кратко и наглядно:

Решения простое и изящное. Однако, в вайтпейпере лишь кратко затрагиваются проблемы управления (в частности, варианты выбора лидера и комитета), перенесение Dapps с EVM (хотя поддержка смарт-контрактов Эфира заявлена), проблемы безопасности Slow Chain во время периодов восстановления, экономика сети, практические решения.

Два гениальных ума, в данный момент, заняты наймом сотрудников на работу. Кто же такие Элейн Ши и Рафаэль Пасс, как они связаны с проектом Аlgorand и светом очей наших, Виталиком? Всё это читай уже в обзоре Шерлоков. А я буду готовить вторую часть, где попытаюсь найти ответы на поставленные мной выше вопросы, по мере поступления новой информации. Да и тебе, я надеюсь, небезразлична судьба Вадима Казаченко. А пока, пристально следим за проектом Thunder Token и записываемся в Евангелисты у них на сайте.

Самый умный глупый,

@CryptoLamer ©

Вместо P.S. Аксиома Ламера: Чем дольше Ламер пишет пост, тем больше пива выпито.