Заполняем форму в Sui Wave 3.0

Sui

SUI анонсировали набор валидаторов на Wave 3.0 Testnet. За это 100% будут награды, так что заполняем. Форма ТЫК.

Валидаторы

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

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

Периоды

Работа сети Sui временно разделена на непересекающиеся периоды примерно фиксированной продолжительности (например, 24 часа) . В конкретную эпоху набор валидаторов, участвующих в сети, и их право голоса фиксированы. На границе эпохи может произойти реконфигурация, которая может изменить набор валидаторов, участвующих в сети, и их право голоса. Концептуально реконфигурация запускает новый экземпляр протокола Sui с окончательным состоянием предыдущей эпохи в качестве генезиса и новым набором валидаторов в качестве операторов. Помимо изменений набора валидаторов, на границах эпох также обрабатываются операции токеномики, такие как делегированная ставка/анстейкинг и распределение вознаграждений за стейкинг.

Кворумы

Кворум — это набор валидаторов, чья совокупная сила голоса составляет> 2/3 от общего числа в течение определенной эпохи Например, в экземпляре Sui, которым управляют четыре валидатора с одинаковым правом голоса, любая группа, состоящая из трех валидаторов, является кворумом.

Размер кворума >2/3 выбран для обеспечения устойчивости к византийским отказам (BFT) . Как мы увидим, валидатор зафиксирует транзакцию (т. е. надежно сохранит транзакцию и обновит свое внутреннее состояние с учетом результатов транзакции) только в том случае, если она будет сопровождаться криптографическими подписями от кворума. Мы называем комбинацию транзакции и подписей кворума на ее байтах сертификатом . Политика фиксации только сертификатов обеспечивает византийскую отказоустойчивость: если > 2/3 валидаторов добросовестно следуют протоколу, они гарантированно в конечном итоге согласятся как с набором зафиксированных сертификатов, так и с их последствиями.

Пишите запросы

Валидатор может обрабатывать два типа запросов на запись: транзакции и сертификаты. На высоком уровне клиент:

  • передает транзакцию кворуму валидаторов для сбора подписей, необходимых для формирования сертификата.
  • отправляет сертификат валидатору для фиксации изменений состояния на этом валидаторе.

Транзакции

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

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

Сертификаты

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

Как и в случае с транзакциями, отметим, что процесс обмена сертификатом с валидаторами можно распараллелить и (при желании) передать на аутсорсинг стороннему поставщику услуг. Клиент должен транслировать свой сертификат более чем 1/3 валидаторов, чтобы гарантировать, что (с точностью до предположений BFT) хотя бы один честный валидатор выполнил и зафиксировал сертификат. Другие валидаторы могут узнать о сертификате через синхронизацию состояний между валидаторами или через синхронизацию состояний с помощью клиента.

Роль Нарвала и Акулы

Sui использует преимущества Narwhal и Tusk: Mempool на основе DAG и Efficient BFT Consensus, а также преемника Tusk Bullshark . Mysten Labs также внедряет Narwhal/Bullshark (N/B), поэтому, когда требуется византийское соглашение, мы используем высокопроизводительный консенсус на основе DAG для управления общими блокировками, в то время как выполнение на разных общих объектах выполняется параллельно.

Narwhal обеспечивает параллельное упорядочивание транзакций в пакеты, которые собираются в одновременно предлагаемые блоки, а Bullshark определяет алгоритм выполнения DAG, который формируют эти блоки. Объединение N/B строит DAG блоков, предлагаемых одновременно, и создает порядок между этими блоками как побочный продукт построения DAG. Но этот порядок накладывается поверх причинно-следственного порядка транзакций Sui («полезная нагрузка» Narwhal/Bullshark здесь) и не заменяет его:

  • Narwhal/Bullshark работает в режиме OX, а не в режиме XO (O = приказ, X = выполнение); выполнение происходит после приказа Нарвала / Акулы.
  • Таким образом, результатом N/B является последовательность транзакций, взаимозависимости которых хранятся в самих данных транзакции.

Консенсус упорядочивает сертификаты транзакций. Они представляют собой транзакции, которые уже были представлены 2/3 валидаторов, которые проверили, что все принадлежащие им объекты доступны для работы, и подписали транзакцию. После секвенирования сертификата мы устанавливаем блокировку общих объектов в следующей доступной версии, чтобы сопоставить выполнение этого сертификата. Так, например, если у нас есть общий объект X версии 2, и мы упорядочиваем сертификат T, мы сохраняем T -> [(X, 2)]. Это все, что мы делаем, когда достигаем консенсуса, и в результате мы можем принимать множество последовательных транзакций.

Теперь, как только это будет сделано, Sui может выполнять все сертификаты, для которых были установлены блокировки, на одном или нескольких ядрах (в настоящее время). Очевидно, что транзакции для более ранних версий объектов должны быть обработаны в первую очередь (каузально), и это снижает степень параллелизма. Набор для чтения и записи транзакции может быть статически определен из ее версионированных входных данных объекта — выполнение может читать/записывать только объект, который был входом для транзакции или который был создан транзакцией.

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: