Соучредитель Solana: Создание глобального конечного автомата и анализ идеальной архитектуры Solana

**Слова: Анатолий Яковенко, генеральный директор (соучредитель и генеральный директор), Solana

Составитель: 1912212.eth, Форсайт-новости

Цель Solana — как можно быстрее синхронизировать единый, не требующий разрешений глобальный конечный автомат в соответствии с законами физики. Полагаю, архитектура, которая сможет этого достичь, будет выглядеть следующим образом:

• Большое количество полных узлов, более 10 000 (N > 10 000)

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

• Большое количество лидеров генерации блоков, более 10 000 (N > 10 000)
• Одновременные лидеры производят блоки, выбранные случайным образом в диапазоне от 4 до 16.

Concurrency Leader позволяет сети иметь несколько местоположений по всему миру для упорядочивания пользовательских транзакций. Это сокращает расстояние между пользователями и сетью, устраняя необходимость полной проверки узла перед добавлением транзакций в цепочку.

• Время блока 120 миллисекунд

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

• Некоторые из узлов консенсуса при голосовании в подкомитете по утверждению, с числом от 200 до 400, выбираются случайным образом и меняются каждые 4-8 часов в эпоху.

Консенсус необходим для выбора форка, который происходит из-за разделения сети. Выборка из 200 или более узлов будет статистически репрезентативной для всех основных разделов сети и близко соответствовать их фактическому распределению. Поэтому все голоса полных узлов не требуются, достаточно 200. Ограничьте утверждение подкомитетами, чтобы уменьшить объем памяти и пропускную способность сети, необходимые для поддержки блоков длительностью 120 мс. Сокращение времени блока, естественно, увеличивает количество голосов, отправляемых в секунду, оказывая некоторое давление на ресурсы, выделяемые для консенсуса.

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

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

Асинхронное выполнение

Мотивация

Синхронное выполнение требует, чтобы все узлы, которые голосуют и создают блоки, были суперсконфигурированы в любом блоке, чтобы определить наихудшее время выполнения. Асинхронное выполнение — один из немногих случаев, когда компромиссов немного. Узлы консенсуса могут выполнять меньше работы перед голосованием. Работа может быть агрегирована и пакетирована, что делает ее выполнение эффективным без потери кэша. Он даже может быть выполнен на совершенно другой машине, чем узел консенсуса или лидер. Пользователи, которым требуется синхронное выполнение, могут выделить достаточно аппаратных ресурсов для выполнения каждого перехода состояния в режиме реального времени, не дожидаясь охвата всей сети.

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

ОБЗОР

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

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

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

Все транзакции без права голоса могут быть рассчитаны асинхронно. Это позволяет replay выполнять все транзакции без голосования пакетами, выполнять предварительную выборку и JIT-компиляцию всех программ заранее, практически исключая потерю кэша. Долгосрочная цель состоит в том, чтобы для этой задачи были настроены только компьютеры, которым требуются вычисления в режиме реального времени с низкой задержкой и полным состоянием. Предположительно, пользователи будут платить за дополнительное оборудование.

После того, как выбор вилки и выполнение состояния разделены, ускорить процесс становится проще:

• Асинхронное выполнение
• Каждую эпоху происходит ротация фиксированного количества комитетов по голосованию
• Время блока 200 мс

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

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

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

Проголосовать

• Аккаунты для голосования должны иметь достаточное количество SOL для покрытия голосов 2 эпох.
• Процедуры голосования должны быть простыми. Непростое голосование обречено на провал. Блочные генераторы должны отказаться от сложного голосования.
• Вывод SOL со счетов для голосования разрешен до тех пор, пока баланс не упадет менее чем на 1 эпоху голосов.
• Для того, чтобы обнулить все лампорты, директива Vote CLOSE должна требовать истечения полной эпохи. Учетные записи для голосования помечены как ЗАКРЫТЫЕ в Эре 1, но могут быть ЗАКРЫТЫ только в Эре 2. CLOSE позволяет вывести все SOL и удалить учетные записи для голосования. После того, как учетная запись помечена как ЗАКРЫТАЯ, она может быть только полностью удалена и не может быть открыта повторно.
• Голоса содержат VoteBankHash вместо обычного BankHash.

Регулирование и утверждение лидера

Только валидаторы соответствуют следующим критериям:

• Сумма ставки > X
• А также SOL > 2 эпохи голосования
• и не помечен как CLOSE

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

Расчет VoteBankHash

В отличие от Bankhash, который вычисляет все транзакции, валидаторы вычисляют VoteBankHash только для простых транзакций голосования, связанных с валидаторами в LeaderScheduler. Все остальные транзакции игнорируются. После повторного воспроизведения всех голосов VoteBankHash вычисляется в том же формате, что и текущий BankHash.

VoteBankHash должен накапливать предыдущий VoteBankHash, а не полный BankHash.

Вычисления BankHash

Для всех оптимистичных подтвержденных блоков (настраивается для всех блоков) валидатор начинает вычисление UserBankHash, который включает в себя все переходы состояний, но исключает транзакции, которые были учтены при расчете VoteBankHash.

Затем BankHash является производным от накопления (VoteBankHash, UserBankHash). Лучшие 99,5% валидаторов отправляют BankHash в рамках своего голосования каждые 100 временных интервалов. Несмотря на то, что он фиксируется каждые 100 временных интервалов, он рассчитывается в каждом временном интервале. Стоит отметить, что для небольшого процента узлов может быть полезно последовательно отправлять BankHash в сплетнях в качестве мягкого сигнала, не наблюдающего недетерминированного.

Если менее 67% валидаторов отправляют полные вычисления BankHash, лидеры должны уменьшить пространство блока, доступное для пользовательских транзакций и учетных записей, доступных для записи, на 50%. Эта мера призвана защитить цепочку от злоупотреблений, которые могут чрезмерно увеличить время воспроизведения.

BankHash должен накапливать предыдущие BankHashes.

Идите к руководителю банка

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

• Лидеры ведут кэш оплаченных остатков на счетах.
• Если платная учетная запись используется в качестве источника для системных переводов или в качестве записываемой учетной записи, передаваемой вместе с системной программой в другую программу, то баланс платного счета устанавливается равным 0.
• Блоки упаковываются в соответствии с объявленными вычислительными единицами (CU) в локальном порядке приоритета комиссий до тех пор, пока блоки не будут заполнены.
• Комиссии вычитаются из кэша оплаченного баланса аккаунта.
• Платное кэширование баланса аккаунта дополнено расчетами BankHash.

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

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

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

Компромиссы

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

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

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

Долгосрочная дорожная карта узла консенсуса без сохранения состояния

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

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

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