Децентрализация является одним из ключевых слов технологии blockchain: появились компании и веб-сайты, которые включают это слово в свое имя.
Децентрализация рекламировалась как самая продвинутая особенность финтех. Аббревиатура DLT (Decentralized Ledger Technology) стала синонимом blockchain в разрешенной среде Fintech.
Мало кто понимает, что децентрализация сама по себе является проблемой, и в течение многих лет технология blockchain останавливается.
Позволь мне объяснить:
В 1960-х годах, компьютерные системы были централизованы или настроены как топология сети звезда. Только в начале 1970-х годов, необходимость подключения компьютеров нескольких производителей стала насущной.
В то время, узлы нескольких существующих сетей связи, были организованы иерархически, но с самого начала протоколы, реализованные в узлах ARPA, RPCNET, PISA и других новаторских сетей, предшествующих Интернету, были разработаны с общей идеей, что Центральный узел или орган должен контролировать, руководить, быть центром или владеть сетью.
Другими словами, мы знали, что централизованная многоуровневая сеть звезда, с ее врожденными узкими местами, не сможет удовлетворить даже потребности тысяч пользователей в 1970-х годах. Мы также предположили, что за счет сокращения числа узких мест в результате децентрализации, проблема будет уменьшена, но не решена. Мы знали, что решение должно использовать распределенную одноранговую модель.
Поскольку многие организации будут задействованы в предоставлении узлов, каналов, и ненадежного аппаратного и программного обеспечения, мы предполагали, что сеть ненадежна. Мы не знали, как согласованный набор данных или даже одна транзакция, могут поддерживаться в нескольких базах данных через ненадежную сеть, когда любой узел может генерировать сообщение, или в терминологии финтех, финансовую транзакцию. Проблема была еще более усугублена присутствием злонамеренных игроков.
Почему blockchain технология препятствует идее децентрализации
В общих чертах, мы признаем, что сеть децентрализована, когда управление сетью совместно используется подмножеством узлов сети.
Сеть распределяется, когда все узлы в равной степени разделяют обязанности и запускают одно и то же программное обеспечение узла.
Децентрализованные (разрешенные и основанные на лидерах) сети часто являлись расширениями централизованных сетей, вытекающих из требований приложений, например, в сфере финтех-индустрии.
Сетевое программное обеспечение blockchain (базовое системное программное обеспечение) не должно разрабатываться в соответствии с требованиями приложения, поскольку они будут меняться. Мы не проектировали сетевые предшественники Интернета и самого Интернета, основываясь только на требованиях приложений 1970-х годов. Мы не могли бы предсказать, какие отрасли будут развиваться, основываясь на способности обмениваться информацией в глобальном масштабе.
Точно так же базовая сеть blockchain, должна быть максимально общей, гибкой и масштабируемой. Разрешения, клиент-сервер и требования частной сети, могут тогда рассматриваться как особые случаи распределенной сети, например, с использованием концепции виртуальных частных (blockchain) сетей.
Распределенные сети с большей вероятностью, не зависят от какой-либо конкретной физической структуры. Узлы могут динамически соединяться друг с другом, и могут использоваться процедуры случайного соединения. Консенсусные решения, реализованные в распределенных сетях, также могут быть недопустимыми, управляемыми большинством и рекурсивными.
Распределение, а не децентрализация, должны были стать основной целью проектирования криптосетей.
Почему мы потерпели неудачу
Неспособность исследовать соглашения о распределенном консенсусе, частично обусловлена формулировкой проблемы византийских генералов в 1982 году, которая моделирует, как можно поддерживать целостность информации в ненадежной среде. Проблема византийских генералов изучалась исследователями более тридцати лет.
Аналогия нескольких союзных армейских дивизий, удерживавших осажденный город, предполагала, что никому на поле нельзя доверять, чтобы доставить сообщение, и что некоторым из самих генералов нельзя было доверять при выдаче команды.
Однако формулировка армейской аналогии, предполагала наличие как минимум двух классов войск: генералов и солдат.
Затем некоторые люди ограничивали свое более конкретным случаем, когда генералы давали команды, которые нужно было как передавать другим генералам, так и защищать от вмешательства со стороны злоумышленников или предателей.
В конце концов, этот подход привел к ограниченному определению проблемы консенсуса.
Модели консенсуса, основанные на лидерах, такие как Paxos и Raft, преподавались в университетах и использовались в качестве моделей, разработчиками blockchain сетей.
В результате практические решения проблемы византийских генералов, были сосредоточены на различных методах выбора узла-лидера, который отправлял бы блок проверенной информации всем остальным узлам вместо того, чтобы пытаться достичь консенсуса по содержанию блока.
Отсутствует цель
Консенсус относительно того, какой узел должен быть текущим лидером, не решает проблему доверия. Текущий лидер должен быть доверенным. Он должен выполнять работу по проверке и сборке блоков справедливым образом.
Таким образом, на основе текущих протоколов консенсуса, лидер должен предоставить некоторые полномочия: proof of work, proof of stake, доказательство способности или доказательство чего-либо еще.
Эти «доказательства» не гарантируют нечего больше, чем личный интерес, который могут иметь узлы-лидеры (или узлы, стремящиеся быть узлами-лидерами) в сети: чем больше процентов они приобретают, тем меньше они будут готовы уничтожить свою форму дохода.
Эти «доказательства» гарантируют, что потенциальные лидеры имеют полномочия, но не гарантируют, что информация, собранная в блоке, является правильной, или, что она была проверена большинством узлов.
Мы увидели более 60 предложенных решений на основе лидерских моделей для различных реализаций blockchain. Они страдают от общей ошибки: один узел решает, что будет хранить каждый другой узел в blockchain. Результат почти противоположен тому, что требуется.
Резюме недостатков основанных на лидере протоколов
Протоколы на основе лидера имеют следующие недостатки:
- Они не решают проблему доверия. Узел-лидер может вводить ошибочные данные, намеренно или нет, в блок информации.
- Награды, связанные с работой по проверке и сборке блоков, создают стимул для узлов, что бы конкурировать за награды и продвигаться на руководящие должности. Этот стимул имеет тенденцию создавать специальный класс узлов. Сеть превращается в децентрализованную сеть. Например, Bitcoin начинался как сеть партнеров, где каждый узел мог проверять транзакции и бороться за вознаграждение. Сегодня это сеть двух классов (майнеры и пользователи), которая управляется владельцами больших пулов.
- Когда сборка блока передается одному узлу, одно из основных требований теории консенсуса становится недействительным: соглашение не основано на консенсусе большинства о том, какая информация будет храниться в blockchain. Единственное достигнутое соглашение — это метод выбора узла-лидера.
- Вводится узкое место, или единичная точка отказа: один узел должен транслировать блок каждому другому узлу.
- Эффективность не самая лучшая: большие блоки данных больше подвержены ошибкам передачи и повторной передаче пакетов максимального размера.
- Избыточность составляет почти 100%: каждая транзакция, включенная в блок, уже была получена каждым узлом отдельно, когда транзакция была первоначально выполнена.
Лучшая аналогия
Размышляя об аналогии с проблемой достижения общего решения в неорганизованной и ненадежной среде, мы могли бы использовать аналогию армии без званий, но она не была бы очень интуитивной.
Лучшей аналогией, могла бы стать задача определения ежедневной цены закрытия на фондовой бирже. По этой аналогии множество покупателей и продавцов определяет ежедневную цену закрытия акций, используя стохастический процесс, без какого-либо конкретного лица, принимающего решение за кого-либо еще.
На фондовом рынке нет «правильного» ответа на цену акций, а только согласованная дневная цена закрытия.
Аналогично, в составе блока несколько переменных, таких как порядок транзакций, могут определять окончательную композицию блока. Не существует «правильной» композиции блоков, только одна, с которой согласуются узлы.
Консенсусные протоколы, основанные на более распределенной аналогии, могли бы избежать тенденции к централизации и необходимости промежуточных узлов, типичных для основанных на лидере протоколов.
Примеры посредников в сети:
- Майнеры, производители или контролеры, добровольно участвующие или привлеченные для предоставления услуг сети,
- Специальные узлы федеративных систем, которые заинтересованы в успехе сети,
- Узлы, выбранные с некоторыми критериями для управления сетью,
- Узлы, принадлежащие доверенным компаниям или учреждениям,
- Специальные игроки, такие как централизованные валютные биржи, владеющие кошельками пользователей.
Что не так с посредниками?
Прежде всего, это вопрос стоимости: если посредники выполняют полезную работу, например, проверяют транзакции, их нужно вознаграждать.
Это также вопрос доверия: клиенты, использующие сеть с посредниками, должны доверять:
- Что посредник не отдает предпочтения определенным пользователям или транзакциям,
- Что посредник не был или не будет захвачен злоумышленником,
- Что система посредника не отключается, не подвергается атаке DoS, системному отказу или любой другой причине, которая повлияет или задержит транзакции клиента,
- Системное программное обеспечение и данные посредников надежны, поэтому гарантируется целостность и безопасность данных.
- Что они действительно связаны с доверенной системой, а не с подражателем (например, с какой-то другой системой, претендующей на звание доверенного посредника), и
- Что никакого другого непредсказуемого события не произойдет. Недавно, например, владелец канадской валютной биржи Quadriga умер или исчез. В результате миллионы долларов средств клиентов отсутствуют.
Наконец, это вопрос доступности данных. Если в сети есть привилегированный или ограниченный класс узлов, управляющих blockchain, то большинство узлов не имеют мгновенного доступа к текущей реплике blockchain. Это может помешать разработке приложений реального времени, таких как приложения автоматической торговли.
Не слишком ли поздно менять модель консенсуса в blockchain?
Большинство экспертов скажут вам, что основной функцией согласованных протоколов, является поддержание безопасности сети. Эта точка зрения смешивает две проблемы. Безопасность, необходима, но это совершенно другое требование, которое может быть решено другими способами.
Тем не менее, многие разработчики придерживаются идеи, что консенсус означает выбор лидера, и что консенсус необходим для поддержания безопасности.
Оглядываясь назад, если бы мы думали о лучшей распределенной аналогии, исследование могло бы пойти в другом направлении, предлагая стохастические подходы, и могло бы привести нас к более ранней разработке, лучше распределенных решений без посредников.
Теперь это проблема образования, а не техническая проблема. Большинство исследователей, консультантов и экспертов по криптосетям, владеют всеми деталями PoW, PoS, DPoS и несколькими десятками альтернатив, основанных на одной и той же модели, основанной на лидерах.
Те немногие решения, которые не основаны на лидерах, не являются blockchain-решениями: это решения, где каждая транзакция обрабатывается отдельно.
С другой стороны, большинство людей и 95% компаний, согласно недавнему опросу, понимают потенциал технологии blockchain.
Срочно необходим переход от децентрализованной к распределенной модели, чтобы раскрыть истинный потенциал blockchain, решить проблемы масштабируемости и запустить blockchain на любом пользовательском устройстве без посредников.
Автор: Сергей
