Кластер Solana

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

Создание кластера

Прежде чем запускать какие-либо валидаторы, сначала необходимо создать genesis config. Конфигурация ссылается на два открытых ключа, mint и bootstrap validator. Валидатор, содержащий закрытый ключ валидатора начальной загрузки, отвечает за добавление первых записей в реестр. Он инициализирует свое внутреннее состояние учетной записью монетного двора. Эта учетная запись будет содержать количество собственных токенов, определенное конфигурацией генезиса. Затем второй валидатор связывается с валидатором начальной загрузки, чтобы зарегистрироваться как валидатор. Затем дополнительные валидаторы регистрируются у любого зарегистрированного члена кластера.

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

Присоединение к кластеру

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

Отправка транзакций в кластер

Клиенты отправляют транзакции на любой порт модуля обработки транзакций (TPU) валидатора. Если узел находится в роли валидатора, он перенаправляет транзакцию назначенному лидеру. Если в роли лидера узел объединяет входящие транзакции, помечает их временными метками, создавая entry, и помещает их на плоскость_данных кластера. Оказавшись в плоскости данных, транзакции проверяются узлами валидации, эффективно добавляя их в реестр.

Подтверждение транзакций

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

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

Масштабируемое подтверждение может быть достигнуто с использованием следующей комбинации методов:

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

Солана меняет лидеров через фиксированные промежутки времени, называемые slots. Каждый лидер может производить записи только в течение отведенного ему слота. Таким образом, лидер ставит метки времени транзакций, чтобы валидаторы могли найти открытый ключ назначенного лидера. Затем лидер подписывает метку времени, чтобы валидатор мог проверить подпись, доказывая, что подписывающая сторона является владельцем открытого ключа назначенного лидера.

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

Пакет транзакций можно разделить столько раз, прежде чем он станет настолько мал, что информация заголовка станет основным потребителем пропускной способности сети. На момент написания этой статьи (декабрь 2021 г.) подход хорошо масштабируется примерно до 1250 валидаторов. Для масштабирования до сотен тысяч валидаторов каждый узел может применять ту же технику, что и узел-лидер, к другому набору узлов равного размера. Мы называем эту технику Turbine Block Propogation.