Блокчейн-дихотомия и архитектура для ее преодоления

Блокчейн-дихотомия и архитектура для ее преодоления

Источник · Перевод автора

Попытка разблокировать массовое принятие для публичной цепочки блоков является одной из самых сложных задач в отрасли сегодня. Настоящим компаниям еще предстоит увидеть ценность технологий публичного блокчейна и сканирования. Я полагаю, что это в значительной степени вызвано блокчейн-дихотомией: поляризация инфраструктурных решений в современной отрасли. Если это действительно является причиной, мы можем спроектировать архитектуры вокруг этого. Будет ли этого достаточно, чтобы принятие стало возможным?

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

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

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

Дихотомия блокчейна

Я считаю, что принятие происходит медленно, потому что наша отрасль сильно поляризована. Решения движутся между двумя противоположными крайностями – и массовое внедрение падает прямо в пропасть.

С одной стороны, у нас есть публичные цепочки блоков, такие как Ethereum, Tezos и Polkadot. Прекрасные решения, но их подход к «публичности» ориентирован на абсолютную децентрализацию бизнеса. Их публичное размещение в основном перекликается с чистыми dapps, новым типом бизнес-модели, которая только начинает появляться. Они стремятся к новому Интернету, где посредников, таких как Uber Ltd, заменяют на новые децентрализованные Ubers, включающие в себя одноранговую экономику токенов вместо традиционной модели коммерческого мира. Проблема, которую эти инфраструктуры решают сегодня, не пользуется большим спросом у существующих основных предприятий, и их оптимизация делает их слишком дорогими и непрактичными для популярного использования.

С другой стороны, у нас есть частные и разрешенные блокчейны, такие как Hyperledger. Они прагматичны и просты в использовании, но дают сомнительное преимущество перед традиционными базами данных. Они не сосредотачиваются на значении отсутствия прав и, следовательно, не могут дать сильных внешних гарантий своим пользователям. Я считаю, что эти решения упускают то, что действительно разрушительно в блокчейне и где стоит большая ценность.

Можно ли преодолеть эту дихотомию? Или эта поляризация присуща самой технологии?

В любом случае, что мы пытаемся решить?

Прежде чем мы сможем начать думать об архитектурах для преодоления дихотомии, нам нужны конкретные определения того, что мы пытаемся решить. Преимущества технологии не ясны для основных предприятий. Итак, какова цель публичного блокчейна?

Первым, что люди говорят в ответ на этот вопрос, обычно является децентрализация – мы пытаемся децентрализовать аспекты бизнеса. При попытке передать децентрализацию бизнесу, первый вопрос, который задают: сделает ли децентрализация меня более прибыльной? Отрасль пытается дать убедительный ответ на этот вопрос.

Я предпочитаю другой ответ. Я рассматриваю прагматичную технологию блокчейна как инфраструктуру для создания приложений, которые предоставляют пользователям три интересные гарантии: возможность аудита, возможность расширения и управление. Я не буду вдаваться в подробности о каждой гарантии, это описано в предыдущем посте. Эти гарантии могут помочь сделать бизнес более прибыльным, увидеть аналогии из движения с открытым исходным кодом.

Теперь, когда у нас есть конкретный ответ, мы можем исследовать, как на самом деле предоставляются эти гарантии.

Блок производителей и валидаторов

Производители блоков, валидаторы, майнеры – все это схожие термины в архитектуре блокчейна. Они относятся к объектам в сети, которым поручено выбирать транзакции, упаковывать их в блоки и подписывать эти блоки как часть процесса согласования. Каждый блок, который проходит консенсус, добавляется в цепочку, создавая цепочку блоков.

Первое интересное различие, которое мы проводим в Orbs, – это разделение между производителями блоков и валидаторами. Производители блоков – это те, кто предлагает блоки, а валидаторы – те, кто подписывает и проверяет их.

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

Теперь, когда предлагается новый блок, он должен пройти консенсус. Этот блок отправляется валидаторам, которые проверяют, что блок следует протоколу. Они проверяют, что транзакции действительно действительны, что выполнение корректно, изменения состояния складываются и так далее. Если они действительны, они подписывают блок. Когда собрано достаточное количество подписей – за пределами согласованного порога – блок принимается и добавляется в цепочку.

Многие блокчейн-архитектуры сегодня используют одни и те же объекты для обеих задач. Производители блоков обычно действуют как валидаторы друг для друга. Обычно есть только одна группа.

Создание разделения между двумя возможными в архитектуре Orbs дает некоторые интересные преимущества и, на мой взгляд, играет важную роль в решении.

Подтверждение кола (Proof-of-stake) и публичный пул валидаторов

В основе экосистемы Orbs лежит пул валидаторов без права доступа, который выбирается держателями токенов ORBS. Я не буду вдаваться в подробности архитектуры Orb-проверки кола и того, как опекуны и делегаты работают вместе для выполнения этой задачи. Смотрите соответствующие сообщения на эту тему.

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

Виртуальные цепочки и автономность управления приложениями

Другим важным элементом архитектуры являются виртуальные цепочки. Сеть Orbs запускает несколько изолированных виртуальных цепочек параллельно в одной физической инфраструктуре узлов и валидаторов. Каждое приложение обычно работает в своей собственной виртуальной цепочке в иллюзии наличия собственной выделенной цепочки блоков.

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

Однако самое важное преимущество не связано с производительностью, оно связано с изоляцией. Различные виртуальные цепочки изолированы, особенно в отношении управления. Каждая виртуальная цепочка имеет свою собственную цепочку блоков, продвигающихся независимо, и свой собственный экземпляр алгоритма согласования, выполняющийся параллельно.

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

Каждое приложение должно объявлять и реализовывать свою модель управления в виде набора интеллектуальных контрактов, работающих в его виртуальной цепочке. Это позволяет каждой виртуальной цепочке принимать собственные независимые решения по управлению, например выбирать алгоритм консенсуса. Что еще мы должны позволить каждому приложению контролировать?

Могут ли приложения выбирать производителей блоков и валидаторов?

Если приложение может свободно принимать решения по управлению в своей виртуальной цепочке, возникает вопрос: может ли приложение выбирать своих собственных производителей блоков? Кроме того, может ли приложение выбирать свои собственные валидаторы?

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

1. Приложения не могут выбирать своих собственных производителей блоков, приложения не могут выбирать своих собственных валидаторов

Если мы не позволяем приложению выбирать идентификаторы той или иной группы, это означает, что обе группы должны быть определены сетью. В случае с Orbs это означает, что обе группы происходят из пула валидаторов без разрешения, выбранного держателями токенов ORBS в соответствии с моделью доказательства кола Orbs.

Этот подход ведет нас к крайней «публичной» стороне дихотомии блокчейна. По сути, это похоже на то, как сегодня работают блокчейны, такие как Ethereum и Tezos. Приложения, работающие на этих блокчейнах, должны, естественно, принимать общедоступных майнеров этих блокчейнов, собранных с использованием систем стимулов, не связанных с приложением.

2. Приложения могут выбирать своих собственных производителей блоков, приложения могут выбирать свои собственные валидаторы

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

Если управление приложением разрешено (например, какой-то объект в приложении вызывает снимки), эти группы будут разрешены. Если управление приложением не разрешено (например, подтверждение участия с использованием вторичного токена приложения), эти группы будут запрещенными, но будут подчиняться собственной модели стимулирования приложения, а не сети. Последствия этого огромны и, вероятно, заслуживают отдельного поста в блоге.

Этот подход ведет нас к крайней «частной» стороне дихотомии блокчейна. В принципе, это похоже на работу блокчейнов, таких как Hyperledger. Приложения, работающие на этих блокчейнах, контролируют их личную судьбу.

Это две крайности, с которыми мы хорошо знакомы. Есть ли третий вариант?

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

Теперь все становится интереснее под архитектурой Orbs. Производители блоков могут быть выбраны приложением – в зависимости от модели управления приложением (с разрешением или без разрешения), но средства проверки назначаются сетью – исходя из общего и разрешенного пула средств проверки Orbs, выбранного держателями токенов ORBS.

Кажется, что этот подход не подпадает ни под одну из крайностей дихотомии. Он падает где-то посередине.

И это захватывающе.

Вернемся к нашим трем гарантиям

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

Давайте на минуту разберемся с вилкой, потому что она, пожалуй, самая интересная из трех. Возможность работы с пользователем – это возможность каждого пользователя приложения по своему усмотрению разветвлять приложение со всем его кодом и данными. Способность форка создает здоровый баланс сил. Если контроль над приложением нарушается и сообщество пользователей или партнеров чувствует себя обиженным в зависимости от выбранной модели управления приложением, это сообщество может легко запустить свой собственный дубликат экземпляра приложения. Они не являются заложниками. Если этого не происходит, и приложение остается популярным форком, это означает, что ни один другой форк не работает лучше. Это подводит итог вилки.

Итак, что нам нужно, чтобы гарантировать пользователям приложения возможность раскошелиться?

Это на самом деле довольно просто. Все, что им нужно, – это доступ ко всем блокам в виртуальной цепочке приложения. Поскольку интеллектуальные контракты хранятся в состоянии, а изменения состояния хранятся в блоках, и код, и данные будут доступны таким образом.

Акт разветвления виртуальной цепочки на Orbs тривиален. Платформа позволяет создавать новый экземпляр разветвленной виртуальной цепочки одним нажатием кнопки, содержащей все блоки из исходной виртуальной цепочки.

Но как мы можем гарантировать доступ к блокам приложения? Как мы можем гарантировать, что показанные нам блоки действительно являются реальными блоками, а не альтернативной историей?

Мы можем сделать это, если внешний пул валидаторов подтвердил доступ к исходным блокам; пул валидаторов, который не находится под непосредственным контролем приложения; общественный пул валидаторов. Так же, как тот, который был выбран держателями токенов ORBS во Вселенной Orbs!

Сравнение матрицы выбора

Обе крайности дихотомии возможны при архитектуре Orbs, но обе имеют существенные недостатки для основного направления.

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

Предоставление приложению полного контроля над производителями и валидаторами блоков – это «частная» крайность. Это очень практично для основного бизнеса, но оказывается, что таким способом невозможно дать три гарантии. Следовательно, этот подход не учитывает то, что мы определили как добавленную стоимость блокчейна. Приложение может также работать на простой старой базе данных.

Но как насчет третьего варианта? Контроль над производителями блоков, но нет контроля над валидаторами.

Формирование общего пула сетевых валидаторов для валидаторов приложений оказывается достаточным, чтобы предоставить нам все три гарантии. Это означает, что добавленная стоимость блокчейна есть. Тем не менее, предоставление приложениям контроля над его производителями блоков имеет большое значение – оно делает решение неожиданно намного более практичным для основных предприятий. Это почему?

Контроль производителей блоков важен для широкого внедрения

Предоставление господствующему приложению контроля над производителями блоков снимает многие опасения слишком агрессивной децентрализации. Это делает процесс перехода на блокчейн осуществимым для существующих предприятий.

Во-первых, он заботится о безопасности. Это может показаться нелогичным, но для основных приложений переход на полностью децентрализованную модель безопасности блокчейна на самом деле увеличивает риск. У Uber нет серьезных проблем с безопасностью, он абсолютно уверен в своей способности защитить свое приложение централизованным способом. Uber не будет переключаться на блокчейн для безопасности. Во всяком случае, Uber будет избегать переключения на блокчейн из-за боязни дать неизвестной группе анонимных узлов полный контроль над собственной безопасностью.

Контроль над производителями своих блоков позволит Uber выступать в роли собственного производителя блоков. Если они не доверяют кому-либо еще, они могут быть единственным производителем блоков, сохраняя свою судьбу в своих руках. Внешние валидаторы только проверяют блоки, но не предлагают их. Даже если все валидаторы вступят в сговор с Uber, они не смогут изменить данные или украсть что-либо. Максимальный ущерб, который они могут нанести, влияет на жизнеспособность приложения. И это не обязательно плохо, потому что если сам Uber будет скомпрометирован плохими актерами, эти валидаторы предотвратят плохие актеры от нанесения вреда пользователям.

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

Запуск валидатора значительно дешевле, чем запуск блочного производителя. Валидаторы могут быть лицами без гражданства. Для Uber запуск собственных производителей блоков практически не отличается от затрат на собственные серверы, как сегодня. Дополнительные расходы на блокчейн отражаются в накладных расходах для валидаторов публичного пула.

В-третьих, акцент делается на добавление гарантий для пользователей, а не на абсолютную децентрализацию. Идея не в том, чтобы снести Uber и заменить его новым полностью децентрализованным Uber. Это не практично, особенно для Uber Ltd. Мы не пытаемся создать новый Интернет. Мы пытаемся улучшить существующие приложения и сделать их более привлекательными для пользователей и партнеров, помогая им предлагать более надежные гарантии. Определение добавленной стоимости публичного блокчейна как способности давать эти гарантии, а не абсолютной децентрализации, внезапно делает добавленную стоимость блокчейна применимой для основного потока.

Постепенная и ответственная децентрализация для приложений

Архитектура Orbs предоставляет приложениям с несколькими уровнями контроля, которые делают переход на блокчейн потенциально постепенным процессом. Это связано с нашим пониманием того, что большинство существующих предприятий не могут децентрализовать в одночасье.

Как это стало возможным для приложения?

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

Во-вторых, контролируя своих производителей блоков. Существующее приложение может начать с того, что является единственным производителем блоков. Платформа все еще может предоставить три гарантии в этом случае. Поскольку приложение готово доверять дополнительным партнерам, например, при расширении своей экосистемы, оно может добавлять дополнительных производителей блоков из доверенных партнеров. Последний шаг – сделать пул производителей блоков без доступа. Приложение может делать это по собственной модели стимулирования или использовать для этой задачи общедоступный пул валидаторов без прав доступа. Это сделало бы последний шаг в «публичную» крайность дихотомии – но только если и когда приложение будет готово.

При желании приложение также может запускаться с «частного» предела дихотомии и даже управлять своими собственными валидаторами. Как мы видели ранее, преимущество блокчейна в этом случае невелико, поскольку три гарантии не будут предоставлены. Добавленная стоимость блокчейна не проявится. Тем не менее, приложения, которые только хотят быть общедоступными, могут начать экспериментировать с этой технологией.

В-третьих, путем разработки собственной модели управления. Модель управления приложением реализована в виде интеллектуальных контрактов, работающих в его виртуальной цепочке. Эта модель управления может начинаться централизованно с единого лица, принимающего все решения. Это дает контроль над существующими приложениями, но не влияет на способность платформы предлагать три гарантии. По мере того как стремление приложения к децентрализации растет, эту модель управления можно модернизировать до более децентрализованной. Например, если приложение имеет собственную экономию токенов, оно может использовать голоса, основанные на ставках, на собственном вторичном токене, чтобы принимать решения по внутреннему управлению чисто децентрализованным способом.

Заключение

Блокчейн-дихотомия сдерживает принятие блокчейна. Решения сегодня либо чрезмерно децентрализованы на «публичной» крайности, либо чрезмерно разрешены на «частной» крайности. Мы можем либо разрушить существующие приложения и построить новый Интернет, либо остаться со старым Интернетом и упустить все, что может предложить блокчейн.

Разделение между производителями блоков и валидаторами может обеспечить недостающую гибкость. Разрешение производителям блоков оставаться «частными», в то же время заставляя валидаторы становиться «общедоступными», позволяет основным приложениям сохранять уровень контроля и сохранять расходы на инфраструктуру в разумных пределах.

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

Я верю, что дихотомия, которую мы видим сегодня, постепенно исчезнет. Обе крайности должны будут предпринять шаги, чтобы стать ближе. Решения для «публичного» экстрима, такие как Ethereum и Tezos, станут более привлекательными для мейнстрима, приняв такие архитектуры, как разделение производителей блоков и валидаторов. Решения о «частном» экстриме добавят византийскую отказоустойчивость и другие идеи из общедоступных блокчейнов, чтобы предоставить более сильные гарантии своим пользователям.

Примите участие с Orbs

  • Посетите веб-сайт, чтобы узнать больше об общедоступной цепочке блоков Orbs.
  • Orbs с открытым исходным кодом! Просмотрите код на Github и внесите свой вклад.
  • Начните разрабатывать приложения на Orbs, просмотрите документацию.