Слой Zero

В который погружается Ламер, чтобы найти причины всех бед Биткойна

Disclaimer: автор данного длиннопоста не претендует на истину в последней инстанции, а лишь доносит до читателя те сведения, которые он добыл, пытаясь разобраться в вопросе. Если тобой отмечены фактические ошибки, то, пожалуйста, сообщи об этом в личном сообщении в телеграме, c описанием неточностей и ссылками на конкретные источники. Благодарю тебя за это!

by CryptoLamer

Приветствую тебя, мой жадный до технологий криптоинвестор. Знаю, что ты ждёшь ответа на вопрос: “Чо ты, мля, так долго страдал херней и ничо нормального не писал уже год?” И я тебе на него не отвечу. Лучше перейдём сразу к делу.

В нашей с тобой любимой крипте существует много проблем. Объективно, их полно. Мы с тобой уже настолько срослись с рынком и смирились с этим, что, в целом, нам уже особо и не важно, кто и чем занимается, лишь бы не пошли по стопам Панина и, желательно, выходили с IEO на Банане… ну, в крайнем случае. на Bitmax… ну, в самом крайнем случае, на Gate… и то, если название проекта вызывает ассоциации с ватерклозетом. А если серьёзно, то вот какие проблемы ты знаешь в технологии блокчейн?…Так, ну? Ну на вот шпаргалку посмотри, жертва IDO.

Ой, это что-то не то. Дай-ка сюда. Откуда это? Так. Подписано…Виталик Б. Хм. Не знаю кто это, но шутка так себе. Ну давай ещё немного подумаем…

Даааа….уже забыли бы с тобой про вс…так стоп, я вообще-то про технологии. В чём главная проблема блокчейна, как технологии…

Так, уберите добрую женщину из поста. Утверждение спорное. Однако есть тому причины и их пытаются решать. И если в прошлом году хайпил один вариант решения проблемы, то в этом году хайп поднялся из-за другого способа решения все той же проблемы. Я бы сказал – это решение диаметрально противоположно существующему. Итак, сегодня мы будем говорить с тобой о головной боли блокчейнов первого, второго поколения, да и для жертв DPoS это тоже вполне справедливо. Поговорим о масштабируемости.

Ну а что делать. если спрос имеется? Да и причины спекулятивные имеются также. Погнали поскребем по сусекам технологии.

Глава 1. Математика медлительности

Начнём с простого. Что вообще такое, эта пресловутая масштабируемость? Как нам её определять? В универе меня учили, а я учился в универе, хотя судя по моим криптоуспехам так сразу и не скажешь, но у меня есть даже вот такая красная штука:

Кстати, очень удобно использовать

Так вот, учили нас в универе, что система называется масштабируемой, если она способна увеличивать свою производительность пропорционально дополнительным ресурсам. Т.е., для блокчейна, работающего на основе механизма PoW, было бы справедливо, если бы при увеличении количества вычислительных ресурсов система работала бы быстрее. А мерой быстрой работы блокчейна для нас с тобой является показатель количества выполненных транзакций в единицу времени (секунду) или Transaction Per Second на басурманском неправославном или ТПС, на русском родимом. Но как мы видим из статистики на satoshi.info, несмотря на рекордный вычислительный ресурс сети…

с годами Bitcoin быстрее не становится

Хотя Segwit, вроде как, пошёл на пользу. Но 7 транзакций в секунду – это максимум, а среднее значение 2,94 TPS – до сих пор незыблемо. Я не вайтпейпер какого-нибудь блокчейна 4.0, чтобы поливать творение Сатоши тем, чем по сути все блокчейны 4.0 и являются. Я лишь хочу вместе с тобой разобраться, почему так. Почему же мы всё вкладываем и вкладываем ресурсы в сеть, строим более мощные асики, а быстрее она не становится? В чем же причина такого поведения?

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

Теперь, обратимся к формулам. Подожди, не убегай. Второй ряд и задние парты, не засыпаем! Знаю, что тебе тяжело. Но я постарался выбросить все сложные равенства и неравенства (однако сексистские шутки всё ещё здесь) и пояснить, буквально на пальцах левой задней лапы своего скотч-терьера, что и как. Итак, TPS – это отношения количества выполненных транзакций в единицу времени или

Распишем эту формулу непосредственно для блокчейна. Итак, TPS для блокчейна – это не что иное, как отношение количества транзакций в одном блоке сети к количеству блоков в единицу времени или

(формула Г, потому что Главная)

Соответственно, у нас есть два способа увеличить скорость обработки транзакций в блокчейне. Либо увеличивая левый множитель “количество транзакций на 1 блок”, либо увеличивая правый множитель “количество блоков в секунду”. Увеличение второго множителя равносильно уменьшению временного интервала между блоками или (как говорим мы, великие блокчейн-Xперты, убеждающие тех кто ничего не знает, что мы что-то знаем, хотя сами ничего не знаем и не понимаем) межблочный интервал.

Понятно, что количество транзакций в 1м блоке можно увеличить только двумя способами:

Уменьшив размер одной транзакции.
Увеличив размер блока.

С первым способом мы с тобой столкнулись, когда пережили SegWit. Подробнее об этом ты можешь почитать, например, вот тут. Но если вкратце, то после SegWit часть информации из транзакции перешла в так называемый “Расширенный блок”, а сама транзакция стала меньше. Я думаю о том, какая именно это часть и в чём тут дело, мы тоже как-нибудь с тобой поговорим подробнее. Касательно же данного сабжа нам нужно лишь знать, что транзакции из тучных американцев, сидящих на фастуфуде, превратились в пакистанских работяг в подвалах Дубаи, и теперь запихнуть их в подвал (блок сети) можно больше, что, собственно, ты можешь наблюдать на графике выше, с октября 17го года.

Второй вариант мы с тобой также, пережили. Теперь у нас есть 32х мегабайтный блок Роджерджихан Кэш и 2х гигабайтный после очередного апгрейда блок Биткойна от истинного Сатоши по мнению никого. Кстати, давай рассмотрим скорости в этих сетях. Coinanalysis утверждает, что средняя скорость в сети BCH составляет 116 TPS, в то время как некоторые стресс-тесты в сети BSV позволили выдать 400 TPS без нарушения работы сети. Да, увеличение существенное, но почему скорости не смогли достигнуть даже 1000 TPS и почему размер блока в этих сетях делать большим просто бессмысленно?

Чем больший объем данных засунут в блок, тем больше данных нода должна верифицировать, дабы защитить сеть от спама. Это как если бы ты хотел избавить мир от преступности и понаписал бы целую тонну законов, но чтобы проверить, преступник ли перед тобой, тебе пришлось бы перечитать каждый из них. Конечно, в данном случае время, затраченное на проверку, увеличивается. Собственно, время проверки информации в блоке (или его валидация), плюс время, затрачиваемое на трансляцию блока в сеть – называется propagation time или время предложения блока в сети. Оно определяется количеством времени, которое пройдёт от момента создания нового блока до момента его проверки и достижения большинства (90-95%) нод сети. А теперь представь, что нода должна создать большой блок, забить его транзакциями, проверить, переслать бОльший объем данных, а остальные также должны убедиться, что всё в порядке. Естественно, в таком случае время предложения блока возрастает и это приводит к одному очень забавному следствию. Чем больше мы ждём блок, тем вероятнее, что мы с тобой увидим что? Правильно, другой блок, созданный быстрее предыдущего. А значит, возрастёт вероятность чего? Совершенно верно! Хардфорков.

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

Нет, я не буду рассказывать тебе о том, как правильно использовать кредитно-грейсовое кольцо. Тут вообще не про займы. Сейчас будем вспоминать, как работают степени и дроби. Итак, вероятность возникновения форка определяется, как

(формула Б, потому что эта Бл*дская сволочь мешает Крейгу разогнаться до скорости света)

Где tp – время предложения блока, а tb – межблочный интервал. При этом, межблочный интервал – это константа, определенная самим протоколом (для BTC и BCH она составляет ~10 минут). Если мы построим график этого математического выражения,

Ламер намутил график экспоненциальной функции (А_ХУ_ЕСТЬ)

то мы увидим, что, действительно, вероятность возникновения форка тем выше, чем больше отношение tp/tb. Т.е., учитывая, что tb – некая постоянная величина, определенная протоколом, то при росте времени предложения блока в сеть (tp)- повышается вероятность появления другого блока, который будет быстрее предложен этой сети. При этом, если время предложения блока в сеть tp превышает межблочный интервал tb, то ясно, что сеть просто перестанет работать. Ведь тогда сеть наводнят множество блоков, которые ноды ещё не успели валидировать, а значит, управление балансами превратится в хаос. Это чем-то похоже на Человека-муравья в его гиперогромном обличье, он становится мощнее, но гораздо медленнее.

Отсюда Вывод 1: Увеличение размера блока влияет на время распространения блока по сети (или времени предложения блока в сеть) что, в свою очередь, ведет к увеличению вероятности возникновения альтернативных цепочек. А уж если время предложения блока в сеть превысит межблочный интервал, то можно жмякать рубильник в положение OFF. Мы приплыли, господа.

Тогда, может быть, увеличить второй множитель в формуле Г, то есть увеличить количество блоков, которые генерируются в единицу времени, т.е. уменьшить этот межблочный интервал tb на уровне протокола? Да, так можно поступить. Например, подстроив алгоритм майнинга под более низкую сложность. Но тогда, согласно формуле Б, уменьшая в протоколе межблочный интервал tb, мы тем самым увеличиваем вероятность возникновения форка. Почему?

И вот тут в наш рассказ вмешивается модель OSI.

Глава 2. От блокчейна к сети

Итак, мы с тобой в той точке, когда изменения в протокол внесены максимальные. Размер блока – слегка увеличили, размер транзакций – уменьшили, алгоритм майнинга – подстроили. Но воз и ныне там, ну, может быть, в пару-тройку раз веселее транзакции забегали. Ну, в крайнем случае, на пару порядков. При этом наши волнение по поводу того, что сеть разделят, как Зиту и Гиту, также выросла на несколько порядков. Спасибо трансцендентным степеням и распределению Пуассона, ага. Но как достигнуть скоростей более централизованных сетей, таких как Ripple и EOS, и при этом сохранить высокую безопасность а.к.а. низкую вероятность разделения сети?

И вот тут нам придётся вернуться к параметру tp или времени предложения блока. Понятно, что он, в большей степени, определяется временем, которое требуется блоку, что бы достигнуть других нод сети. А зависит это время от алгоритма, который используется в протоколе для передачи пакетов с информацией по сети. То есть, фактически, от быстроты интернета нод сети. И как тут не вставить dial-up мемчик…

Ох уж эти 56 килобит счастья! Покупаешь карточку, просишь маму позвонить заранее своим подругам, обсудить все незавершенные дела и БОЛЬШЕ НИКТО ЧТОБЫ НЕ ЗВОНИЛ И ТЕЛЕФОН НИКТО НЕ ТРОГАЛ!!! Можно было скачать 3-5 песенок… да-да ньюфаг, 3-5 песенок с Zaitcev.net, сохранить пару сотен порно-картинок и даже почитать bash.org! Стоп меланхолия! Вернёмся!

Итак, всё зависит от быстроты и качества связи в сети. Так в чём же загвоздка?

Существует такая штука, как Базовая модель взаимодействия открытых систем или сетевая модель OSI. Совсем грубо, это набор протоколов, следуя которым различные устройства в сети могут друг с другом взаимодействовать. В модели OSI всего 7 уровней и каждый из них использует свои протоколы. На каждом уровне определены типы данных, которые передаются на этом уровне. У каждого уровня свои функции. Если лень лезть в википедию, то всё сводится в одну простую таблицу.

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

когда пытаешься разглядеть размер своего депозита после ликвидации на Bitmex

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

старый добрый баян

Именно о работе блокчейн-протокола на сетевом уровне говорим мы, когда говорим о масштабируемости на нулевом уровне. Механизм маршрутизации пакетов и адресации на этом уровне как раз определяется протоколом. И здесь уже всё зависит не столько от скорости интернета, а именно что от самого механизма, который определяет метод передачи пакетов. И для биткойна он максимально безопасный, но при этом максимально медленный. Для того, чтобы защитить сеть от DDoS-атак, когда сеть наводняют микротранзакции, с целью вывести ноды из работы сети, сеть Bitcoin работает по схеме store-and-forward или, как её называем мы – Иваны Лаптевы – буферизированная коммутация. Как тебе позволяют понять твои неограниченные знания забугорного, на практике это означает, что нода должна дождаться получения блока из сети целиком, сохранить его у себя в буфере, проверить его валидность и только затем отправить дальше. Такая модель позволяет определить, от кого конкретно пришёл некошерный блок, пометить такую ноду в сети как “зловредная вонючка” и сообщить об этом соседям, тем самым снизив активность главгада в сети. Т.е., опять же, выигрываем в безопасности сети. Но, согласно теореме Брюера (тот самый невозможный треугольник), там, где мы выигрываем в безопасности, мы неминуемо проигрываем в скорости.

Тут надо сделать оговорку, что S&F-маршрутизация помогает безопасности протокола именно на уровне сети, то есть, защиту от DDoS-атак и определение целостности пакетов с данными и определяет параметр tp – то есть, время предложения блока в сеть. Собственно, комбинация этих факторов: снижение вероятности форка за счет малого размера блока и сложности решения математической задачи по созданию блока, а также store-and-forward механизм маршрутизации на уровне сети и делают биткойн очень медленным, но офигеть каким безопасным в сравнении с другими распределенными протоколами. Практически таким же безопасным, как твоё одеяло! А что ты не знал, что если прятаться под одеяло, то все подкроватные монстры не могут до тебя добраться? Научный факт, между прочим.

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

Таким образом появляется Вывод 2: чтобы увеличить скорость блокчейна и при этом уменьшить вероятность возникновения форка, достаточно просто изменить механизм маршрутизации пакетов. И ты, логично, спросишь: существует ли такое решение, при котором достаточно изменить механизм работы протокола на сетевом уровне таким образом, чтобы время предложения блока в сеть существенно уменьшилось, что позволило бы снизить межблочный интервал – а значит, увеличить скорость сети, при этом не затрагивая уровень её безопасности? Блин, я бы офигел, если бы ты меня такое спросил на самом деле.

Но факт в том, что такое решение уже давно имеется. Cut-through или, по нашему. сквозная маршрутизация. Смысл её в том, что нода принимает, сохраняет и валидирует не весь блок целиком, а лишь его заголовок, а остальную часть пуляет далее в сеть, не задумываясь о содержимом. Именно так можно уменьшить время предложения блока в сеть. Таким образом, пропускную способность блокчейна можно увеличить на 3-4 порядка. И даже снизив на уровне протокола межблочный интервал, мы можем балансировать вероятностью возникновения форка. Таким образом. вероятность возникновения форка одинакова при 10 минутном межблочном интервале и при секундном межблочном интервале, если время предложения блока в сеть составляет 1 минуту и десятую долю секунды, соответственно. Говоря языком математики, мы хакаем систему, фактически пропорционально уменьшая соотношение tp/tb в формуле Б.

Совершенно верно, мой юный фанат Пуассона! Ведь при S&F-маршрутизации нода видит в блоке некое дерьмо и может об этом сигнализировать в сеть. При cut-through маршрутизации узел сети не проверяет, нет ли внутри самого пакета блока баунти (это когда у негра в попе находят пакетик героина или что-нибудь ещё нехорошее). При этом, также, сети тяжко работать под нагрузкой. То есть, при одновременной передаче пакета от нескольких узлов сети одному конкретному могут возникать, осторожно умное слово, коллизии (обожаю это слово, как будто мороженку лизнул), при которых пакеты просто теряются. Но и этой проблеме нашли решение. Тут помогает…пам-пам-пам…

Пакет данных всегда можно перед отправкой криптографически сжать, при этом добавив в заголовок некое доказательство, которое послужит доказательством неизменяемости пакета на выходе…упс… я, кажется, только что вляпался в zk-пруфы…

Есть и другие, более продвинутые, схемы решения проблемы фильтрации и проверки корректности трафика при сквозной маршрутизации для увеличения безопасности работы сети, но их обсуждают в специальных учебниках на английском языке, страниц так на 400 для программистов какого-нибудь Cisco.

Отличный вопрос, красавчик. Да, действительно, такие решения имеются. И называются они Content Delivery Network или сокращенно CDN. Что это за зверь такой? Ну, буквально то, что заложено в названии. Это сети, оптимизирующую доставку статических данных (таких как видео, музыка, книги и т.п.) конечному пользователю. За счёт чего? За счёт распределенной (ага, уже почуял запах блокчейна и крипты?) географической топологии.

свизженно с википедии

Как это работает? Допустим, у тебя есть сайт lightpornowithIEOonBitMax.com, там хранятся все доказательства твоих мучений в последнем IEO. И находится он на сервере где-нибудь в Нарнии. В то же время клиенты из Средиземья, Вестероса, Нью-Йорка, Москвы и Орехово-Зуево стучатся, чтобы скачать оттуда веселые картинки твоих похождений на IEO. При обычной топологии сети каждый из них шлёт запросы на центральный сервер в Нарнии. Но что если в каждой географической точке поставить DNS-сервер, кэширующий (то есть, буквально, сохраняющий определенные копии или части сайта рядом с конечными пользователями. И теперь пользователю из Орехово-Зуево не обязательно каждый раз стучаться в Нарнию, испытывая колоссальные задержки сигнала. Достаточно обратиться на ближайший DNS-сервер в Москве, чтобы получить определенную копию данных с сайта, и только для получения порции свежего контента уже обращаться на центральный сервер. Таким образом, во-первых, как мы уже поняли, задержки в сети при передаче трафика уменьшаются, как зуд после Бепантена. Из уменьшения сетевых задержек следует, во-вторых, увеличение скорости загрузки контента. И это только то, что мы не видим напрямую. А косвенно получается, что, в-третьих, уменьшается нагрузка на центральный сервер и на узлы сети. И, в четвертых, если всё твое общение сводится с ближайшим к тебе DNS-серверам, то хакнув Нарнийский филиал, хакер не узнает о твоей любви к легкой похабщине на IEO, потому что он не знает кто, как и когда связывался с Московским серваком. Да, да. CDN улучшают приватность. В данный момент свои CDN развернуты у Google, Netflix, Amazon, Alibaba и других малоизвестных, никем не используемых стартапов.

Конечно можно, мой жадный до знаний обитатель Криптоземья. И именно такие решения предлагают нам проекты, которые занимаются решением проблемы масштабируемости блокчейнов на сетевом уровне, то есть, в том самом слое Zero. И если ты думаешь, что сейчас мы их с тобой рассмотрим, то нет… Я слишком ленивая задница, которая итак убила 2 недели на этот длиннопост. Даже сериальчики не смотрел, плак :_( Ну а может быть тебе эта тема покажется не столь интересной.

Переубеди меня! Напиши в комментах тут, или в нашем чате @CryptoSherlockClub, или мне в личном сообщении, понравился ли тебе длиннопост и стоит ли рассказать о конкретных практических решениях проблемы Zero Layer?

Твой сетевой червь,
@CryptoLamer

В длиннопосте использованы материалы следующих статей:

Глава 1. Математика медлительности

Глава 2. От блокчейна к сети

Добавить комментарий Отменить ответ