1/x

Мы рады представить наш @SuiNetwork: Mysticeti, углубленный анализ нового парадигмы консенсуса.

$Sui = Первая Параллельная Исполнение + Молниеносный Консенсус

Рост $Sui основывается на надежной технологической инфраструктуре.
______
Давайте разберемся, почему Mysticeti так привлекателен.

Поздравления: команде $Sui @EmanAbio @0xAmoghGupta @weiduong @EvanWeb3 @theharrisonkim и другим

Поздравления: руководителю исследования ContributionDAO и другим

______
Это довольно долго, но вам стоит выделить время, чтобы прочитать это и получить вдохновение от данного исследования.
______

Mysticeti

В июле $Sui объявила о переходе от использования Narwhal и Bullshark в качестве протокола консенсуса к Mysticeti[1]. В этой статье я постараюсь упростить статью о Mysticeti и объяснить, как он работает и почему он был выбран с моей точки зрения, сохраняя основные идеи.

Обзор Narwhal и Bullshark

Чтобы понять необходимость Mysticeti, давайте сначала рассмотрим Narwhal и Bullshark. Если вы знакомы с этими протоколами, можете перейти к следующему разделу. Для получения дополнительных деталей смотрите ссылки [2], [3] и [4].
Narwhal и Bullshark — это сертифицированные протоколы консенсуса на основе DAG, предназначенные для увеличения пропускной способности системы путем разделения распространения данных и логики консенсуса. Narwhal выполняет роль слоя мемпула, управляя потоком данных, в то время как Bullshark обрабатывает консенсус. Валидаторы интерпретируют свой локальный DAG, созданный Narwhal, без дополнительной коммуникации, что означает, что консенсус не требует коммуникационных затрат, улучшая эффективность.

На высоком уровне Narwhal функционирует как мемпул, позволяя каждому валидатору транслировать сообщения и строить локальное представление DAG. В течение раунда r каждый валидатор транслирует свой блок (вершину) другим валидаторам. Основные элементы каждого блока следующие:

1. Список транзакций,
2. 2f+1 сертификатов из раунда r-1,
3. Подпись валидатора.

Получив блок от другого валидатора, каждый валидатор проверяет его действительность, подписывает его и отправляет обратно первоначальному отправителю. Как только валидатор соберет подписи от 2f+1 различных валидаторов, он может создать сертификат для своего блока и поделиться им с другими. Когда валидатор получает сертификат, он добавляет соответствующий блок (вершину) в свой локальный DAG.
Валидатор переходит к раунду r+1 после получения 2f+1 сертификатов. Полученная структура формирует DAG, поскольку каждый блок ссылается на 2f+1 блоков из предыдущего раунда, создавая ссылки, которые основываются на предыдущих раундах.

Рисунок 1: Структура DAG на основе раундов в Narwhal

Теперь, когда у нас есть DAG, мы можем интерпретировать его с использованием Bullshark. В Bullshark валидатор пытается зафиксировать блоки каждые два раунда. Заимствовав пример из [4], в каждом четном раунде выбирается лидер-блок, который будет использоваться для процесса фиксации. Например, блоки Валидатора 4 (L2) и Валидатора 1 (L4) выбираются в качестве лидер-блоков в раундах 2 и 4 соответственно.

Рисунок 2: L2 и L4 являются лидерами в раундах 2 и 4 соответственно и выделены зеленым цветом.

В следующем нечетном раунде блоки голосуют за лидера в предыдущем раунде, при этом ссылки служат голосами. Например, лидер-блок L2 из раунда 2 получает один голос, поскольку только один блок в раунде 3 ссылается на него. Согласно правилу прямой фиксации, если лидер получает более f+1 голосов, он и его причинно-следственная история могут быть зафиксированы. Таким образом, L4 может быть зафиксирован напрямую, поскольку он получает 2 голоса, тогда как L2 не может.

Рисунок 3: Правило прямой фиксации в Bullshark