Путь Cardano к децентрализации

Перевод статьи Cardano’s path to decentralization - IOHK Blog

Три мини-протокола жизненно важных для работы сети

9 июля 2020 года Marcin Szamotulski

image

Следующие выпуски Cardano и протокола Ouroboros содержат изменения, которые ведут нас к децентрализации и эпохе Shelley. Этот пост от компании Deep Dive объясняет, каким образом мы приближаемся к этой фазе. С выпуском алгоритма Praos для Shelley, который идет вместе с процессом размещения ставок, стейк пулы могут быть настроены таким образом, чтобы владельцы токенов ADA могли делегировать свою часть. Сетевая команда сейчас сосредоточена на двух функциях, которые позволят нам запустить полностью децентрализованную систему. Позвольте мне сначала кратко описать, как устроена и спроектирована сеть, и дать общее представление о том, где мы находимся в данный момент. Этот пост мы начнем в верхней части наших абстракций и пойдем вниз по стеку. Надеюсь, это будет интересное путешествие по нашему дизайну.

Типизированные протоколы

На самом верху стека находится структура типизированных протоколов IOHK, которая позволяет нам разрабатывать протоколы аппликаций. Целью верхнего уровня разработки протокола для Ouroboros является распределение цепочек блоков и транзакций между участниками сети, что, в свою очередь, достигается тремя мини-протоколами:

  • chain-sync используется для эффективной синхронизации цепочки заголовков;
  • block-fetch позволяет нам вытягивать блоки;
  • tx-submission используется для отправки транзакций.

Все три мини-протокола были тщательно разработаны после анализа возможных угроз, которые могут возникнуть при работе децентрализованной системы. Это очень важно, потому что кибератаки очень распространены, особенно они направлены на целевые объекты, которые представляют собой сильные стимулы. Существует целый ряд возможных атак на этом уровне, от которых мы должны быть в состоянии защититься, и один тип атак, к которому мы были крайне внимательны, - это атаки на потребление ресурсов. Чтобы защититься от таких атак, протоколы позволяют потребительской стороне оставаться под контролем того, сколько данных она получит, и в конечном счете поддерживать использование своих ресурсов (например, памяти, CPU (процессора) и открытых файловых дескрипторов) ниже определенного уровня.

Если вас интересует более подробная информация о типизированных протоколах, мы провели переговоры и семинары на мероприятиях Haskell в прошлом году, это было очень эффективно воспринято инженерным сообществом. В частности, смотрите выступление Duncan Coutts на Haskell eXchange и семинар, который я провел на Monadic Party.

Роль мультиплексора

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

Операционные системы ограничивают количество подключений в определенный момент времени. Например, Linux, по умолчанию, может открыть 1,024 соединения на процесс, но на macOS предел составляет всего 256. Чтобы избежать чрезмерного использования ресурсов, мы используем мультиплексор. Это позволяет нам объединить каналы связи в один, так что мы можем запустить все три наших мини-протокола на одном TCP-соединении. Еще один способ сэкономить ресурсы - использовать двунаправленность TCP: это означает, что можно отправлять и получать сообщения на обоих концах одновременно. Мы не использовали эту функцию в эпоху Byron Reboot, но мы хотим воспользоваться ею в децентрализованной эпохе Shelley.

Peer-to-peer компонент (реализация)

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

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

  • “холодные” пиры знают об их существовании, но нет установленного сетевого соединения.
  • “теплые” пиры имеют соединение, но оно используется только для сетевых измерений, и ни один из мини-протоколов node-to-node не используется;
  • “горячие” пиры имеют соединение, которое используется всеми тремя node-to-node мини-протоколами.

Нода потенциально может знать о тысячах “холодных” пиров, поддерживать до сотни “теплых” пиров и иметь десятки “горячих” пиров (20 на данный момент кажется разумной цифрой). Существуют интересные и сложные вопросы, связанные с разработкой политики, которая будет принимать решения для peer-to-peer компонента. Выбор такой политики повлияет на топологию сети и изменит характеристики производительности сети, включая производительность под нагрузкой или вредоносное действие. Это сформирует своевременное распределение диффузии блоков (параметризованное размерами блоков) или транзакций. Поскольку запуск такой системы имеет много неизвестных, мы хотели бы разделить ее на две части. Для начала первой фазы, которая будет выпущена через несколько недель (вероятно, вскоре после Praos, также известного как Shelley release), мы хотим быть готовы со всеми peer-to-peer компонентами, но все еще работающими в федеративном режиме. Кроме того, мы установим диспетчер соединений вместе с реализацией сервера, принимающего соединения, и его интеграцией с peer-to-peer компонентами. На этом этапе peer-to-peer компоненты будут использоваться в качестве механизма подписки. Запуск различных частных и публичных тестовых сетей вместе с нашим обширным тестированием должны добавить нам достаточно уверенности до того, как мы запустим это в основной сети.

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

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

Это уже третий технический пост от разработчиков Deep Dive от наших команд разработчиков программного обеспечения.

// От переводчика: для получения дополнительных переведенных на русский язык статей о Cardano посетите русскоязычный раздел на форуме Cardano. Видеоролики о Cardano на русском можно найти на YouTube канале нашего замечательного амбасадора Тимура Сахабутдинова. Хотите поговорить или задать вопрос о Cardano по-русски? Приглашаем вас в наше уютное сообщество в Telegram. Оставайтесь на связи, все будет хорошо!