Основа кроссчейн коммуникации

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

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

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

Свойства взаимосвязи блокчейна

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

Plug-and-Play подключение.Каждая отдельная сеть должна существовать сама по себе, и для подключения такой сети к другим экосистемам не требуется никаких внутренних изменений. В контексте блокчейнов это означает, что разработчиков платформ не следует принуждать к выполнению каких-либо сложных инженерных задач для подключения к другим экосистемам. Конечно, учитывая полные по Тьюрингу смарт-контракты в некоторых цепочках, заманчиво запрограммировать сложную логику, чтобы понять состояние других платформ, но это в конечном итоге ставит разработчиков в безвыходное положение, когда никто не может обновиться без координации с другими заинтересованными сторонами, с которыми они связаны. к. Например, предположим, что блокчейн A и блокчейн B хотят взаимодействовать. Предположим, что блокчейн A должен наблюдать за каждым действием в блокчейне B и наоборот. Настройка правил разбора транзакций и логики вокруг них — сложная задача. но становится еще хуже, если, скажем, блокчейн B захочет обновиться. Например, если блокчейн B хочет добавить к своему консенсусу новые типы транзакций, то его разработчикам необходимо координировать такие обновления с разработчиками блокчейна A, а затем соответствующим образом обновить логику перехода. И эта проблема масштабируется, если блокчейн B поддерживает N таких соединений с разными сетями. Представьте, что вам нужно запускать обновление программного обеспечения на каждом из ваших периферийных устройств (клавиатура, мышь, iPad) после каждого обновления вашего основного ноутбука или рабочей станции. Вместо этого интеграционные разъемы должны быть максимально легкими и работать по принципу «подключи и работай». затем его разработчикам необходимо координировать такие обновления с разработчиками блокчейна А, а затем соответствующим образом обновить логику перехода. И эта проблема масштабируется, если блокчейн B поддерживает N таких соединений с разными сетями. Представьте, что вам нужно запускать обновление программного обеспечения на каждом из ваших периферийных устройств (клавиатура, мышь, iPad) после каждого обновления вашего основного ноутбука или рабочей станции. Вместо этого интеграционные разъемы должны быть максимально легкими и работать по принципу «подключи и работай». затем его разработчикам необходимо координировать такие обновления с разработчиками блокчейна А, а затем соответствующим образом обновить логику перехода. И эта проблема масштабируется, если блокчейн B поддерживает N таких соединений с разными сетями. Представьте, что вам нужно запускать обновление программного обеспечения на каждом из ваших периферийных устройств (клавиатура, мышь, iPad) после каждого обновления вашего основного ноутбука или рабочей станции. Вместо этого интеграционные разъемы должны быть максимально легкими и работать по принципу «подключи и работай».

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

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

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

Чтобы упростить обсуждение, исправим некоторые обозначения. Предположим, что последовательность блокчейнов (X_1, …, X_n) хочет взаимодействовать, и предположим, что сеть взаимодействия Y, поддерживающая децентрализованный протокол, отвечает за взаимодействие между X_i. Пусть F будет порогом повреждения, который Y может допустить (например, стандартные византийские протоколы имеют порог повреждения 1/3 — другими словами, если 1/3 операторов узлов вступают в сговор, они могут сломать сеть).

Децентрализация. Как мы уже говорили, в сети должно быть как можно больше валидаторов для максимальной безопасности. Для участия в протоколе должны быть как экономические, так и коммунальные стимулы. Сообщество и операторы узлов должны управлять протоколом. Вредоносное поведение должно быть идентифицируемым и устраняться на уровне протокола.
Максимальная безопасность. Во многих системах блокчейна только несколько майнеров или валидаторов могут вступить в сговор, чтобы нарушить безопасность протоколов. Поскольку интероперабельные сети защищают и передают большие суммы средств, безопасность в этих сетях должна быть максимальной, чтобы почти всем операторам узлов пришлось вступить в сговор, чтобы взломать ее. Протокол должен поддерживать высокие пороги безопасности (например, F > 0,9), чтобы увеличить стоимость атак. Высокие пороги безопасности в сочетании с максимальной децентрализацией создают сеть, которую трудно скомпрометировать.
Кроссчейн Живучесть. Жизнеспособность сетей взаимодействия должна гарантировать, что запросы от источника X_i к получателю X_j выполняются атомарно. Таким образом, для любых двух цепей X_i и X_j и сети взаимодействия Y в середине, предполагая, что X_i, X_j и Y добиваются прогресса в соответствии с их правилами консенсуса, тогда в будущем есть время, когда любой запрос от X_i -> X_j должным образом оформлены в установленные сроки.
Механизмы возврата. Когда порог F максимален, сразу же возникает вопрос, что происходит, когда > (1-F) операторов узлов взаимодействия переходят в автономный режим. Традиционные блокчейны в этих случаях останавливаются, однако для сетей совместимости у нас есть возможность добиться большего. Свойство отката интероперабельности утверждает, что если Y останавливается, то существует другой протокол P, который может быть вызван другим (и потенциально гораздо большим) набором операторов для:

а) восстановить любые активы, которые могли быть заблокированы Y, и/или,

б) зафиксировать состояние блокчейнов X_i.

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

Совместное управление. Другой вектор атаки, который мы должны учитывать, когда разрешаем цепочкам взаимодействовать, — это то, что происходит, когда какая-то цепочка X_i нарушает свои правила. Например, предположим, что «большой» блокчейн X_1, такой как Ethereum, взаимодействует с небольшим блокчейном X_2. Что произойдет, если X_2 нарушит свои предположения о безопасности и, скажем, произведет форк? Необходимо применять комбинацию сетевых правил, правил сообщества и социального управления, чтобы решить, что произойдет, когда предположения о доверии X_2 будут нарушены. Должно ли его состояние быть заморожено на X_1? Должен ли он быть отключен от взаимодействия с X_1? Если X_2 подключен к другим цепочкам блоков X_3, … X_n, то следует поощрять согласованность между состоянием X_2 на разных платформах.

Легко увидеть, насколько сложной быстро становится проблема. Но если вы соответствуете основным принципам проектирования функциональной совместимости и дополнительным свойствам, изложенным выше, тогда:

а) Существует постоянный объем работы по созданию протокола взаимодействия, за которым следует постоянный объем работы по подключению каждого нового блокчейна B_i. Другими словами, работа по масштабированию интероперабельности линейна.

б) Преимущества правильной архитектуры квадратичны : любое приложение в любой цепочке X_i может взаимодействовать с X_j через Y, используя унифицированный подход API/шлюза.

c) Работа должна быть сосредоточена на максимальной децентрализации, безопасности, жизнеспособности и управлении одной объединенной сетью.

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