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

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

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

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

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

Часть I. Принципы взаимосвязанности Серфа и Кана.

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

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

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

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

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

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

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

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

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

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

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

Ссылки

[1] https://www.cybertelecom.org/notes/tcpip.htm

[2] Vinton G. Cerf and Robert E. Kahn. A Protocol for Packet Network Intercommunication. https://www.cs.princeton.edu/courses/archive/fall06/cos561/papers/cerf74.pdf

Спасибо за внимание! Оригинал статьи вы можете найти здесь или здесь