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