Почему совместимость блокчейна — это просто модное словечко

И почему существующие сети блокчейна все еще похожи на интернет-сети начала 80-х.

Каждый день мы просматриваем веб-сайты и взаимодействуем с различным контентом с десятков серверов, сетей и географических местоположений. Каждая веб-страница содержит ссылки на другие веб-сайты, фреймы, изображения, видео, всплывающие окна, соединяющие ее с другими веб-страницами. Что делает эти взаимодействия возможными? Ответ кроется в протоколах и сетях, созданных на протяжении десятилетий, и API-интерфейсах, расположенных поверх этой инфраструктуры, которые позволяют разработчикам отправлять контент по всему миру. Такие протоколы, как TCP, IP, BGP и HTTP, определяют стандарты связи, поставщики услуг Интернета управляют базовыми сетями, а сети взаимосвязи таких компаний, как Akamai, эффективно доставляют пакеты из одной сети в другую. API-интерфейсы, подобные тем, которые поддерживаются Twilio, упрощают построение поверх стека.

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

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

Часть I. Принципы взаимосвязанности Cerf и Kahn’s.

Необходимость подключения сетей не нова. Мы видели, как это разыгрывалось во время развития Интернета. Инженеры придумали, как заставить устройства общаться друг с другом в одной сети, было создано множество сетей с разными приложениями и пользователями, поэтому возникла необходимость их соединения. Протоколы маршрутизации (например, IP, BGP), службы именования (DNS), а также протоколы передачи и уровня приложений (например, UDP, TCP, HTTP) были разработаны для доставки трафика по сетям и автономным системам.

Винтон Г. Серф и Роберт Э. Кан изложили некоторые основы интернет-протоколов и разработали основные принципы межсетевого взаимодействия [1, 2]. Это предметы первой необходимости. Вы должны получить их правильно. Создание системы, которая действительно их удовлетворяет, — совсем другое дело.

Итак, давайте вспомним основные принципы, которым должна удовлетворять любая система функциональной совместимости, соединяющая отдельные сети с Интернетом [1]:

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

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

Часть II. Существующий ландшафт функциональной совместимости блокчейна.

Существующие решения для функциональной совместимости блокчейна можно отнести к одному из следующих сегментов:

Централизованные или федеративные системы. Очень немногие или даже одна организация контролирует и управляет разработкой и развертыванием протоколов и систем.
«Мосты» между блокчейнами. Мы видим несколько централизованных мостов, где валидаторы назначаются группе представителей, что не соответствует цели децентрализации. Мы также видим несколько децентрализованных систем, в которых логика перехода состояния цепочки A анализируется цепочкой B (исходно или в смарт-контрактах). Они по своей сути не соответствуют свойству № 1 (среди прочих). Во-первых, для их разработки требуется сложная инженерия — это невероятно тяжелые протоколы, и мы видели годы их развертывания. Во-вторых, если изменяется одна цепочка, то должна измениться и логика перехода состояний во всех других цепочках, зависящих от нее. Анализ логики перехода состояния одной сети на языки другой и наоборот по своей сути не масштабируется.
Кластеры взаимодействия между некоторой цепочкой без разрешений и их дочерними боковыми цепочками (подсетями). Несколько проектов разрабатывают свои собственные цепи без разрешений и позволяют клиентам запускать боковые цепи/коцепи/парачейны, которые взаимодействуют через хаб. Я большой поклонник многих из этих экосистем. Они могут обеспечить взаимодействие между своими сайдчейнами, потому что сайдчейны говорят на одном языке, разрабатываются и поддерживаются одними и теми же поставщиками платформ. Но эти протоколы направлены на развитие экосистемы вокруг основной цепи. Я бы классифицировал их по аналогии с Интернет-провайдерами, которые предлагают пользователям хорошее «локальное подключение». Эти хабы должны использовать другие технологии для связи с другими хабами и блокчейнами, говорящими на разных языках.

В результате протоколы взаимосвязи блокчейна находятся примерно в том же состоянии, что и интернет-протоколы в начале 80-х годов. Другими словами, есть большой потенциал для улучшения! Нам нужны глобальные схемы именования, протоколы обнаружения адресов, протоколы именования, масштабируемые алгоритмы маршрутизации. Нам нужны эти эквиваленты «IP» или «BGP». Нам нужны системы, которые поддерживают эти протоколы и придерживаются основных принципов, разработанных и проверенных Серфом, Каном и другими на протяжении десятилетий. Конечно, протоколы блокчейна имеют свои особенности и свойства, важные для нашей экосистемы, такие как доверие, аутентификация и целостность информации.

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

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

И почему существующие сети блокчейна все еще похожи на интернет-сети начала 80-х.

Часть I. Принципы взаимосвязанности Cerf и Kahn’s.

Часть II. Существующий ландшафт функциональной совместимости блокчейна.

Рекомендации