Перевод официальной документации Chia Blockchain
Цель этого документа: объяснить версию 1.1 алгоритма консенсуса Chia
Целевая аудитория: техническая аудитория, знакомая с блокчейном, но не знакомая с Proofs of Space (PoS), Proofs of Time / Verifiable Delay Functions (VDF) и Chia.
Если вы новичок в Биткойне / блокчейне, сначала прочтите учебник: Биткойн и криптовалютные технологии.
Цель: Алгоритм Chia консенсус направлен на создание экологически чистой, безопасной и децентрализованной альтернативы Доказательству проделанной работы (PoW).
Алгоритм Доказательство выполнения работы (PoW) криптовалюты сжигает огромное количество электроэнергии. Кроме того, он имеет тенденцию становиться централизованным из-за концентрации производства и владения оборудованием, а также из-за концентрации дешевой энергии, что делает PoW недоступным для обычных пользователей и уязвимым для различных атак.
Концепция Proof of stake или PoS (доказательство владения) имеет множество форм, каждая из которых имеет свои плюсы и минусы. Некоторые общие недостатки: концентрированный контроль фондовыми биржами; концентрация делегации; использование контрольно-пропускных пунктов и субъективность (требование регулярно быть в сети); недоступность для обычных пользователей; различные риски; синхронизация часов, пропускная способность сети и другие предположения о безопасности.
Введение
Децентрализованные алгоритмы консенсуса требуют устойчивости Sybel с ограниченными (не бесконечными) криптографически проверяемыми ресурсами. В предыдущих системах блокчейнов ограниченными ресурсами были вычислительные мощности и ставки. Доказательство пространства (Proof of space) — это альтернатива, которая намного ближе к исходному идеалу Биткойна «один процессор - один голос», поскольку используется емкость хранилища как ограниченный ресурс. Например, человек, который хранит 500 ГБ, имеет 5 «голосов», человек, который хранит 100 ГБ, имеет 1 «голос», где голосование означает возможность выиграть и подтвердить блок, а не фактическое голосование по цепочке. Однако использование только емкости хранения небезопасно. Другая часть криптографического пазла используется для защиты системы: а именно проверяемая функция задержки, которая является криптографическим доказательством того, что прошло реальное время. Честная система может быть создана путем объединения доказательств пространства и времени. В такой системе пользователи хранят случайные данные на своих жестких дисках в течение определенного периода времени, и их шансы выиграть Chia пропорциональны выделенному ими пространству. Кроме того, такая система масштабируется до миллиардов участников аналогично лотерее доказательства работы. Для присоединения не требуется никаких средств, специального оборудования, регистрации или авторизации, только жесткий диск. Система полностью прозрачна и детерминирована - любой может эффективно и объективно проверить, какая цепочка является канонической.
Proofs of Space (Доказательство пространства)
Протокол Доказательства пространства — это протокол, в котором:
1. Верификатор может отправить вызов тестировщику, и
2. Тестировщик может продемонстрировать верефикатору, что тестировщик резервирует определенный объем дискового пространства в это конкретное время.
Протокол Доказательства пространства состоит из трех элементов: отслеживание, тестирование / фарминг и верификация.
Рисунок 1: первое, провайдер «плоты» или выделяет часть дискового пространства (1). Затем провайдер «фермы», отвечают на вызовы с Доказательство пространства (2,3,4). Верификатор проверяет, что Доказательство действительности для этого вызова.
Плоттинг — это процесс, с помощью которого тестировщик, которого мы называем фармером, инициализирует определенный объем пространства. Фармером может быть любой, у кого есть как минимум 100 GiB для резервирования на своем ноутбуке, или предприятие, готовое выделить большой объем неиспользуемого дискового пространства. Верхнего предела нет. Плоттинг занимает несколько часов или дней и выполняется только один раз. Инициализированное пространство занимает файл с именем Плот. Плот размеры определяются параметром k, где Пространство = 780 * k * pow (2, k - 10), при минимальном k равном 32 (101,4 GiB). Начиная с Chia 1.0, график k32 может быть создан примерно за шесть часов с помощью быстрой товарной машине и за 24 часа на медленной машине с использованием одного ядра процессора и нескольких ГБ памяти. Есть возможности для огромного ускорения. Конструкция PosSpace основана на BeyondHellman, но вложена 6 раз и содержит другие эвристикие элементы.
В результате получается плот файл размером, например, 100 GiB. Файл содержит семь таблиц со случайными данными. В каждой таблице 2 ^ k записей. Каждая запись в таблице i содержит два индикатора для таблицы i-1 (таблица выше). Наконец, каждая запись в таблице 1 содержит пару целых чисел от 0 до 2 ^ k, называемых «значениями x». Доказательство наличия пространства - это набор из 64 значений x, которые имеют определенную математическую связь.
На диаграмме выше, как только Prover инициализирует 100 ГиБ, они готовы принять вызов и создать доказательство. Одним из привлекательных свойств этой схемы является то, что она не интерактивна: для создания сюжета не требуется регистрации или подключения к Интернету. Ничто не попадает в блокчейн, пока не будет заработано вознаграждение, как в PoW.
Фарминг — это процесс, с помощью которого фармеру дается ряд задач, чтобы продемонстрировать, что он законно зарезервировал определенный объем хранилища. В ответ на каждый вызов фармер проверяет свои плоты, генерирует доказательства и отправляет все доказательства выигрыша в сеть для верификации.
Каждая итерация этого процесса - поиск в таблице. Поиск принимает 256-битный запрос в качестве входных и выходных доказательств. Фармер отвечает на запрос, читая значения в таблице 7. Они указывают на две записи в таблице 6 и так далее. В итоге фармер получает полное дерево значений-x. Для этого требуется одно чтение для таблицы 7, два для таблицы 6, четыре для таблицы 5 и т.д. Весь процесс займет около 640 мс, если предположить, что жесткий диск медленный то время поиска составляет 10 мс. Объем считываемых данных невелик и не зависит от размера плота.
Поскольку большая часть доказательств, генерируемых этим процессом, недостаточно хороша (объясним позже) для отправки в сеть для верификации, мы можем оптимизировать этот процесс, проверив только одну ветвь дерева, которая дает два значения x, в зависимости от задачи. Затем мы хешируем сгенерированные таким образом значения x в 256-битную строку, чтобы определить, хорош ли тест. Хеширование этих значений x дает нам строку качества, 256-битное случайное значение. Это сочетается со сложностью и размером плота для создания необходимых повторений. Если необходимые повторения меньше определенного числа (мы можем войти в блокчейн), мы ищем все PoSpace. Для поиска одной ветки требуется всего около 7 операций поиска и чтения на диске или около 70 мс на медленном жестком диске.
Рисунок 2: Структура файла графика. 64 красный x - значения представляют собой доказательство, 2 зеленый x - значения представляют квалификацию.
Другая оптимизация заключается в том, чтобы дисквалифицировать определенную часть (например, 511/512) плотов правомочности для каждого испытания. Это называется плот фильтром. Например, требуется, чтобы хеш задачи и плот ID начинались с 9 нулей. Это вредит всем одинаково (кроме пополнения атакующих) и, следовательно, справедливо. Это делает фарминг практически без ресурсов и требует очень небольшого количества операций чтения с диска каждые несколько минут. Пользователи Чиа успешно использовали несколько PiB хранилищ на одном Raspberry Pi. Мы предполагаем, что фармеры по-прежнему используют жесткие диски, потому что они дешевые и нет причин использовать SSD поскольку скорость не имеет отношение к фармингу. Однако, для более быстрого сканирования можно использовать диски SSD / RAM.
Плот ключ — это приватный ключ, который хранится в плот файле. Плот ID генерируется путем хеширования открытого плот ключа и открытого ключа пула. Создание блока с доказательством пространства требует подписи с обоих как плот ключа, так и ключа пула. Следовательно, пул нельзя изменить после создания плота. На практике плот ключ представляет собой совокупный открытый ключ 2/2 BLS между локальным ключом, хранящимся в плоте, и ключом, хранящимся в программном обеспечении фармера. По соображениям безопасности и эффективности, фармер может запустить централизованный сервер, используя эту схему ключей и подписей. Сервер может быть подключен ко многим харверстер машинам, на которых хранятся плоты. Для фарминга требуются ключ фармера и локальный ключ, но не пул ключ, так как пул подпись может быть кэширована и повторно использована для многих блоков.
Верификация: после того, как фармер успешно создал доказательство пространства, его можно проверить, выполнив некоторое хеширование и сравнив x-значения теста. Помните, что Доказательство представляет собой список из 64 значений x, где каждое значение x имеет длину k бит длину. Для k32 это 256 байт, поэтому он очень компактен. Проверка выполняется очень быстро, но недостаточно быстро, чтобы проверить ее надежность в Ethereum (что позволило бы передавать данные между цепочками без доверия), поскольку для этого требуются операции blake3 и chacha8.
Доказательства времени
Доказательство времени или Проверяемая функция задержки — это доказательство того, что последовательная функция выполнялась определенное количество раз.
Верифицируемая: это означает, что после завершения расчета (что требует времени) тестировщик может создать очень небольшой тест за очень короткое время, а верификатор может проверить этот тест без необходимости повторять весь расчет.
Задержка: это означает, что доказывающий фактически потратил фактическое количество времени (хотя мы точно не знаем, сколько времени), чтобы вычислить функцию.
Функция: это означает, что она детерминирована: вычисление VDF на входе x всегда дает один и тот же результат y.
Ключевое слово здесь - «последовательный», как и многократное хеширование: hash (hash (hash (a))) и т.д. Это означает, что тестировщик не может просто покупать больше машин, чтобы работать быстрее, в отличие от Биткойн / доказательства работы. Следовательно, мы можем предположить, что для расчета VDF требуется реальное время. Используемая нами конструкция — это повторяющийся квадрат. Тестировщик должен решить задачу x T раз. Это требует времени ϴ (T). Тестировщик также должен предоставить доказательства того, что это было успешно.
Рисунок 3: Верификатор (блокчейн) отправляет запрос тестеру (лорду времени), и тестер вычисляет результат и доказательство.
Хотя следующие детали не очень важны для понимания алгоритма консенсуса, выбор VDF для использования важен, потому что, если злоумышленнику удастся получить гораздо более быструю машину, возможны атаки.
VDF, используемый Чиа, повторяется путем возведения в квадрат группы классов неизвестного порядка. Есть два основных способа создать большую группу с неизвестным порядком. Первый - использовать модуль RSA и использовать целые числа по модулю N как группу. Порядок группы неизвестен, если вы можете сгенерировать свой модуль с множеством участвующих сторон, используя церемонию MPC. Более простой подход - использовать группы классов с большим простым дискриминантом, которые являются группами неизвестного порядка. Для этого не требуется сложной или надежной настройки, поэтому мы выбрали этот вариант для Чиа. Чтобы создать одну из этих групп, вам нужно только большое случайное простое число. Обратной стороной является то, что код группы классов меньше тестируется в реальной жизни, а оптимизация менее известна, чем в группах RSA. Мы используем тот же начальный элемент для квадрата (a = 2, b = 1 элемент группы классов) и вместо этого используем задачу для генерации нового случайного простого числа для каждого VDF, которое используется в качестве дискриминанта. Дискриминант имеет размер 1024 бита, что означает, что размер доказательства составляет около 1024 бита. Мы используем схему Весоловского, разделенную на n (1 <= n <= 64) фаз, так что создание тестов происходит очень быстро. Поскольку доказательства n-Весоловского могут быть большими, мы заменяем их доказательствами 1-Весоловского, так как только они становятся доступными, поскольку они меньше, но требуют больше времени для создания. Сами доказательства не привязаны к цепочке, поэтому их можно заменить.
НастройкаНапомним, VDF принимают входные данные, называемый заданием, и выдают результат вместе с доказательством, подтверждающим, что функция была оценена правильно.
Внедрение значения в VDF означает, что это значение объединяется с выходом из VDF, чтобы сгенерировать новое значение, которое используется как ввод / запрос для следующего VDF. Поэтому, мы объединяем VDF в цепочку, но фиксируем новое промежуточное значение (блок). Это используется для того, чтобы у нас была линейная последовательность блоков, чередуя доказательства пространства с доказательствами времени.
Алгоритм консенсуса
Подписи BLSВсякий раз, когда в этом документе упоминаются подписи, предполагается, что используется детерминированная подпись BLS в соответствии со спецификацией IETF с расширенной схемой. Закрытые ключи, которые запускают эти цифровые подписи, контролируются и хранятся фармерами, и для каждого плота используется уникальный закрытый ключ.
Роли узлов
ФармерыФармеры это узлы, которые участвуют в алгоритме консенсуса, сохраняя плоты и проверяя их на наличие свободного пространства. Они обмениваются данными с полным узлом (обычно на одной машине). Фармеры также обмениваются данными с одним или несколькими харверстерами, которые представляют собой службу, которая находится на машине, на которой хранятся плоты, и ищет доказательства наличия пространства от имени фармерского процесса.
ТаймлордТаймлорд это узлы, которые участвуют в алгоритме консенсуса, составляя доказательства времени и вливая блоки в свои VDF.
Полные узлыПолные узлы могут быть таймлордами или фармерами, или они могут просто выполнять роли полного узла. Это влечет за собой широковещательную передачу доказательств пространства и времени, создание блоков, поддержку пула ожидающих транзакций, хранение хронологии цепочки блоков и загрузку блоков на другие полные узлы, а также в кошельки (легкие клиенты).
ВызовыАлгоритм консенсуса Чиа основан на запуске VDF в течение периодов времени, называемых sub-плотами, которые периодически корректируются, чтобы в сумме составлять около 10 минут. Вызовы публикуются периодически, инициируя своего рода мини-лотерею, в которой фармеры проверяют свои участки на предмет наличия свободного пространства. Когда фармеры находят подходящее доказательство наличия пространства, они транслируют его в сеть. Изменения сложности, чтобы таргетировать 32 выигрышных доказательства в рамках всей сети в каждом sub-слоте. Эти доказательства вводится в VDF в разное время в sub-слот. Фармеры следуют самой тяжелой цепочке, которая представляет собой цепочку с наибольшей совокупной сложностью (обычно цепочку с наибольшим количеством блоков).
Рисунок 4: Три вспомогательных слота. Ось x представляет время. Пунктирные линии представляют выполнение VDF, продвигающееся во времени слева направо. Стрелки представляют хеш-зависимости (объект, указывающий на другой объект, включает хеш второго объекта).
На рисунке 4 мы видим три точки вызова: c1, c2 и c3. В точках c1, c2 и c3 шкалы времени создают проблемы (256-битные хеши), которые предоставляются в качестве входных данных для VDF. Таймлорды берут эти хеши и начинают вычислять VDF для этой задачи для указанного количества итераций. В этом примере каждый слот - это 100000000 итераций. Когда VDF завершен, хронометрист публикует новый вызов и доказательство VDF. Вливание информации о конце слота происходит в конце каждого sub-слота.
Sub-слот: сегмент фиксированного числа интеграций VDF, при условии корректировки сложности задания, всегда приспосабливаясь к фиксированному количеству целевого времени (например, 10 минут).
Итерации sub-слота: периодически настраиваемая константа, определяющая, сколько итераций VDF должен иметь каждый sub-слот.
Вызовы: выходная строка sha256, которая используется в качестве доказательства пространства, трудности для фармерских плотов, а также для цепочки вызовов VDF. Это также называется хешем вызова.
Как вы можете видеть на рисунке 4, одновременно выполняются три VDF, каждая из которых служит для своей цели. Подробности в следующем разделе.
Сигнальные точки и точки инфузии.
Каждый sub-слот в цепочке задач и разделен на 64 меньших VDF, и между каждым из этих небольших VDF есть точка, называемая Меткой. Таймлорд публикуют результаты и доказательства VDF, когда они достигают каждой точки указателя. Обратите внимание, что и цепочка испытаний, и цепочки вознаграждениц имеют указатели (но не встроенную цепочку задач). Число итераций между каждой точкой обозначения равно sp интервал итераций, которые равны итерациям sub-слота / 64.
Вызов в начале sub-слота также является действительной точкой разметки. При достижении каждой из 64 точек сигнализации они передаются по сети с помощью таймлордов и узлов. Фармеры получают эти ключевые точки и рассчитывают фильтр участка на основе ключевой точки, ее идентификатора участка и задачи sub-слота. Если биты плот фильтр начинаются с 9 нулей, проходит фильтр для этой точки указателя и может продолжаться. Это дисквалифицирует около 511/512 всех файлов трассировки в сети для данной отмеченной точки.
plot filter bits = sha256(plot id + sub slot challenge + signage point)
Доказательство пространства вычисляется как хеш битов плот фильтра.
pos challenge = sha256(plot filter bits)
Используя эту задачу фармеры получают качественные данные для каждого участка, прошедшего через дисковый фильтр. Помните, что этот процесс происходит почти мгновенно и что сигнальная точка - это хеш, полученный из части доказательства пространства (но полное доказательство пространства еще не получено).
Фармер вычисляет необходимые итерации для каждого доказательства наличия пространства. Если требуемые итерации <sp интервал итераций, доказательство наличия пространства может быть включено в блокчейн, поэтому фармер извлекает все доказательство пространства с диска (что занимает больше времени, чем просто получение качества), создает незавершенный sub блок и транслирует его в сеть. Обратите внимание, что подавляющее большинство требуемых итераций будет слишком большим, поскольку в среднем 32 будут соответствовать требованиям для всей сети для каждого вспомогательного слота. Это случайный процесс, поэтому большое количество доказательств может быть квалифицировано, но очень маловероятно. Итерации точки указателя - это количество итераций от начала sub-слота до точки указателя.
Итерации инфлюзии - это количество итераций от начала sub-слота, при котором блок с указанным выше качеством может быть включен в блокчейн. Это рассчитывается как:
infusion iterations =( signage point iterations + 3 * sp interval iterations + required iterations) % sub slot iterations
Таким образом, итерации инфузии будут между 3 и 4 сигнальными точками после сигнальной точки. Фармеры должны представить свои доказательства и блоки до достижения точки инфузии. Модуль предназначен для того, чтобы разрешить переполнение в следующий sub-слот, если точка сигнализации находится рядом с концом sub-слота. Это будет подробнее рассмотрено позже.
В точке инфузии блок фармера объединяется с выходом VDF точки инфузии, чтобы создать новый вход для VDF с этой точки, то есть мы вливаем блок фармера в VDF. Блок является полностью действительным только после того, как были достигнуты итерации инфузии, и доказательство VDF было прикреплено к блоку.
Чтобы блок b1 был действительным /завершенным, необходимо включить два доказательства VDF: одно от r1 до точки указателя и одно от r1 до b1. (на самом деле больше, поскольку есть три строки VDF, которые будут объяснены позже). На рисунке 5 фармер создает в момент размещения указателя (назовем его B1 ’). Однако B1 ’еще не закончен, так как ему нужна точка инфузии VDF. После того, как VDF итераций вливания выпущен, он добавляется в B1 ’для формирования законченного блока в B1.
Рисунок 5: таймлорды времени создают доказательства как для точки вывески, так и для точки инфузии. Но они только вливают (изменяют группу классов VDF) для последнего. Квадратные символы обозначают инфузии, при которых запускается новый VDF. Sp интервальные итерации = 3,125 млн.
Рассмотрим пример на рисунке 5. Итераций sub-слота составляет 200 млн, а итераций с интервалом sp - 3,125 млн. Допустим, у фармера всего 1000 плотов.
Для каждой из 64 точек указателя, поскольку они передаются в сеть каждые 9 секунд или каждые 3,125 млн итераций, фармер вычисляет плот фильтр и видит, сколько плотов прошло. Для каждого плота, прошедшего фильтр для каждого указателя, фармер вычисляет необходимые итерации. В этом примере фармер получает только запрошенную итерацию <3,125 млн один раз за весь sub-слот (скажем, 2,2879 млн). На Рисунке 5 это 14-я точка указателя. Итерации инфузии рассчитываются как:
infusion iterations = signage point iterations + 3 * sp interval iterations + required iterations
= 14*3.125M + 3 * 3.125M + 2.2879M
= 55.4129M
Осознав, что они выиграли (в точке 14 инфузии), фармер извлекает полное доказательство пространства, устанавливает блокировку, которая необязательно включает транзакции, и передает ее в сеть. У них есть несколько секунд (до итераций инфузии), чтобы достичь таймлордов, которые вливают блок, создавая VDF точки инфузии. С помощью этих VDF блок может быть завершен и добавлен в блокчейн.
Интервальные итерации Sp: определяется как нижний предел (итераций sub-слота / 64).
Точки обозначения: 64 промежуточных точки во времени в sub-слоте в цепочках испытаний, для которых периодически выпускаются VDF. В каждой точке обозначения создается выходной сигнал VDF, который транслируется по сети. Первый указатель в sub-слоте - это сам вызов. В каждом блоке есть указатель, так что доказательство свободного пространства в блоке должно соответствовать критериям для этого указателя.
Необходимые итерации: число, вычисляемое с использованием строки качества, используемое для выбора доказательств наличия пространства, подходящих для создания блоков. Для подавляющего большинства доказательств наличия пространства потребуется слишком большое количество итераций, которые не могут быть включены в цепочку. Это число используется для вычисления точки инфузии.
Точки инфузии: точка времени на итерациях инфузии из точки вызова для доказательства наличия пространства с определенной задачей и итерациями инфузии. На этом этапе блок фармера вливается в цепочку вознаграждений VDF. Точка инфузии блока всегда находится между 3 и 4 точками указателя после точки указателя этого блока. Вычисляется как итерации точки указателя + 3 * интервальных итерации sp + требуемые итерации.
Задержка между точкой обозначения и точкой инфузии имеет много преимуществ, включая защиту от сиротства и эгоистичного фарминга, уменьшение количества разветвлений и отсутствие пауз VDF. Эта задержка около 30 секунд дается для того, чтобы у фармеров было достаточно времени, чтобы подписать, не задерживая слот VDF. Хорошие фармеры подписывают только одну точку обозначения с каждым доказательством наличия пространства, а это означает, что злоумышленники не могут легко реорганизовать цепочку.
Множественные блоки
Рисунок 7: Множественные блоки. Sp1 = указатели 1
Как вы можете видеть на рисунке 7, множественные блоки могут, быть вставлены в один и тот же sub-слот. Система Чиа ориентируется на 32 блока для sub-слота и это регулируется с помощью алгоритма сложности работы. VDF переходят от предыдущей точки инфузии к текущей точке обозначения и от предыдущей точки инфузии к текущей точке инфузии. Обратите внимание, что доказательства VDF, необходимые для каждого блока, они могут перекрываться. Например, B2 содержит доказательство VDF от B1 до sp2 и от B1 до B2. B3 содержит доказательство от B1 до sp3 и от B2 до B3. B2 совсем не зависит от B3, но B3 зависит от B2, поскольку его VDF исходит из точки инфузии B2. Опять же, блоки создаются в точках указателей, но в них отсутствует точка инфузии VDF; как только этот VDF добавлен, блок завершается и образует часть блокчейн. В точке инфузии подписей нет; единственное, что добавляется в точку инфузии, - это VDF.
Три цепочки VDF
Если бы мы использовали только один VDF (для цепочки вознаграждений), включение или исключение блоков позволило бы контролировать задачу для следующего слота. Это означает, что злоумышленник может попробовать множество различных комбинаций и выбрать наиболее подходящую для него задачи. Эти типы атак называются шлифовальными атаками, и они являются одной из основных трудностей перехода от Доказательство работы к Доказательству пространства или PoStake. Более подробная информация представлена в разделе «Атаки и меры противодействия».
Чтобы смягчить это, проблемы будут основаны только на первом блоке, который будет добавлен в слот.
Рисунок 8: три цепочки VDF. Злоумышленник может манипулировать результатами цепочки вознаграждений, но это не влияет на c2 и, следовательно, не влияет на лотерею PoSpace. cc = цепочка задач, rc = цепочка вознаграждений, sp = точка указателей. B = блок.
На этой диаграмме много всего происходит. Прежде всего, как видите, есть 4 блока: B1, B2, B3, B4, это блоки, созданные фармерами, которые содержат все данные, на которые они указывают. Мы предполагаем, что в этом sub-слоте создано более 5 блоков, но мы не рисуем их все из-за нехватки места.
Кроме того, как цепочка задач, так и цепочка вознаграждений создают 64 точки указателей. Блоки должны включать обозначения точек VDF для обеих цепочек. Блоки также должны включать в себя VDF точки инфузии для всех трех цепочек.
Как вы можете видеть, цепочка вызовов выполняет VDF от начала sub-слота до конца, ничего не добавляя в него (круги - доказательства VDF, но они не прерывают VDF). Цепочке вознаграждений пронизывает каждый включенный блок. Цепочка в середине называется цепочкой добавленных вызовов, и она начинается с первого введенного блока для каждой задачи и продолжается до конца слота.
Слот - это список sub-слотов, которые содержат не менее 16 блоков цепочки вознаграждений на основе задачи первого sub-слота или более поздних sub-слотов. Например, у нас может быть только 10 блоков в sub-слоте, а затем 3, а затем 7, что означает, что эти три sub-слота образуют один слот. Обычно каждый sub-слот также является слотом, так как в среднем включается намного больше 16 блоков. Дефицит - это количество блоков, которое еще необходимо для завершения слота: это будет более подробно описано ниже.
В конце временного интервала цепочки вызовов объединяется с внедренной цепочкой вызовов для генерации нового вызова c2, который используется для запуска цепочки вызовов для следующего sub-слота.
Единственный блок, который влияет на цепочка вызовов, - это первый блок, которым в данном случае является B1, и только детерминированная часть B1, cc B1, которая зависит только от данных цепочки вызовов. Атакующий, который хочет размолот, не может изменить задачу, удерживая B2, B3 или любой другой блок, кроме первого.
Предполагая, что у злоумышленника самый быстрый блок (B1), у него есть три варианта: удержать его, отложить или отпустить. Чтобы узнать, пойдет ли им на пользу новая задача, им нужно будет выполнить VDF полностью до c2. К тому времени у них больше нет шансов попасть в цепочка вознаграждений, поскольку честные фармеры подписывают только один блок за каждое доказательство наличия пространства. Удержание B1 не дает злоумышленнику особой выгоды, поскольку он должен освободить его до sp2, чтобы включить фармеров в свою цепочку. Фармеры выберут самую тяжелую цепочку, в которой будет больше всего (самых тяжелых) блоков цепочки вознаграждения.
Почему мы вообще берем на себя обязательства по каким-либо блокам в цепочку задач? Что ж, если бы мы этого не сделали, злоумышленник мог бы смотреть в будущее с более быстрым VDF, поскольку им не требовалась бы помощь честных участников для вычисления цепочки вызовов в будущем. Цепочка вызовов будет полностью детерминированной. Это дало бы некоторое преимущество за счет повторного построения графика. Кроме того, цепочку задач можно использовать для вероятностного доказательства веса цепочкувознаграждений для простых клиентов, не разделяя все блоки цепочки вознаграждений (поскольку цепочкивызовов зависит от «лучшего» блока в слоте, вы можете рассчитать количество вознаграждений блоков цепочки).
Цепочка заданий: Цепочка VDF, основанная на каждой задаче для каждого sub-слота, которая ничего не вливает в середину каждого sub-слота. Вызовы также используются для доказательства пространства. Указатели в этой цепочка используются для фильтра SP.
Цепочка вознаграждений: Цепочка VDF, которая содержит вливания всех блоков. Эта цепочка втягивает цепьвызовов и, возможно, встроенную цепочка вызовов в конце каждого sub-слота.
Наполнение цепочки заданий: цепочка VDF, которая начинается с первого блока, вставленного в слот (который не основан на вызове предыдущего слота, это называется блоком вызова) и заканчивается в конце слота.
Слот: список sub-слотов, которые содержат не менее 16 блоков цепочки вознаграждений на основе задачи первого sub-слота или более поздних sub-слотов. В конце слота цепочка введенных вызовов останавливается, цепочка вызовов вытягивает результат введенной цепочки вызовов, и дефицит сбрасывается до 16.
Блок: блок - это набор данных, введенных в цепочка вознаграждений, который содержит: доказательство наличия пространства для хеша задачи с меньшим количеством итераций, чем итераций слота, VDF sp и ip для обеих цепочке, необязательный IP VDF для внедренной цепочки вызовов, и адрес вознаграждения. Некоторые блоки также являются блоками транзакций. Максимум 128 блоков на слот.
Блок транзакции: блок, который имеет право создавать транзакции вместе со связанным списком транзакций.
Блок вызова: первый блок, который будет добавлен в каждый слот, который не основан на вызове предыдущего слота. Блок вызова всегда имеет дефицит 15, и всегда начинается с цепочки введенных вызовов.
Пик: пик блокчейна с точки зрения узла - это блок с наибольшим весом. Вес - это сумма сложности блока и всех его предков, которая аналогична высоте, но более короткая цепочка может иметь больший вес из-за сложности настройки.
Чтобы блок считался действительным, он должен предоставлять VDF для цепочки вызовов и цепочки вознаграждений и, необязательно, для внедренной цепочки вызовов, если она присутствует. Принудительное включение всех VDF означает, что все три цепочки будут двигаться вперед с одинаковой скоростью.
Блоки переполнения
Чтобы фармер мог создать блок, их необходимые итерации должны быть меньше 3,125M, или количество итераций под-слота / 64, как описано выше. Это означает, что итераций инфузии может быть больше, чем итераций sub-слота, и поэтому инфузия должна происходить в следующем sub-слоте.
Блок переполнения: блок, точка инфузии которого находится в другом sub-слоте, в отличии от его точки указателя.
Задача текущего слота: в отношении определенного блока B задачи текущего слота B включают в себя все испытания, начинающиеся с первой задачи в слоте и заканчивающиеся концом слота (не включительно). Это актуально, потому что иногда слот охватывает несколько sub-слотов и, следовательно, несколько проблем.
Рисунок 9: B4 на этой диаграмме представляет собой блок переполнения, поскольку инфузия находится в следующем слоте. B4 не основан на вызове текущего слота и, таким образом, не уменьшает дефицит или не создает блок вызова. TODO: диаграмм должно быть 16, а не 5.
Блоки переполнения не могут существовать в первом sub-слоте эпохи (поскольку итерации sub-слота меняются).
Кроме того, блоки переполнения не меняют дефицит, если они не основаны на вызове текущего слота, поскольку блоки переполнения - это ответы на вызов предыдущего sub-слота. Блоки переполнения не являются блоками запроса, если они не основаны на текущем слоте запроса. Обратите внимание, что блоки переполнения редко уменьшают дефицит, так как дефицит почти всегда будет уменьшаться до нуля, и новый слот будет запускаться в каждом sub-слоте.
Минимальные требования к блоку
В цепочку вознаграждений должно быть добавлено не менее 16 блоков задач текущего слота, чтобы слот был завершен.
Дефицит - это число от 0 до 16, которое присутствует в начале sub-слота. Это определяется как количество блоков цепочки вознаграждений, которые нам нужно добавить, чтобы закончить слот. Он сбрасывается до 16 всякий раз, когда мы запускаем слот (поэтому должно быть не менее 16 общих блоков на вливание цепочки вызовов). Дефицит уменьшается для каждого вливания цепочки вознаграждений, основанного на задаче текущего слота.
Блок с дефицитом 15 — это блок вызова.
Нормальный случай — это когда дефицит начинается с 16, снижается до нуля в пределах sub-слота и сбрасывается обратно до 16, когда мы заканчиваем слот и начинаем новый. В случае, если нам не удается уменьшить его до 0 в конце слота, цепочка вызовов и введенная цепочка вызовов (если есть) продолжаются, и дефицит не сбрасывается до 16. Блоки (включая блоки переполнения), продолжайте вычитать из дефицита, пока не достигнем 0. Когда мы заканчиваем sub-интервал с нулевым дефицитом, добавленная цепочка вызовов включается в цепочка вызовов, и дефицит сбрасывается до 16.
Это требование добавлено для предотвращения дальних аттак и подробно описано в разделе «Контрмеры». Подавляющее большинство sub-слотов будет иметь> = 5 блоков, поэтому это не сильно влияет на нормальную работу.
Рис. 10: c2 - это конец вспомогательного слота, но не конец слота. c2 НЕ указывает на ic2, поскольку слот не заканчивался на этом sub-слоте. Дефицит равен 2 вместо сброса до 5, и цепочка заданий продолжается.
Вес
Вес блока – это сумма сложности этого блока плюс все предыдущие блоки, которые являются предками этого блока. Подленные полные узлы должны выбирать пик блокчейна, так чтобы пик был блоком с самым тяжелым весом, о котором они знают. Это важнейшее требование, идентичное правилу самой тяжелой цепочки Биткойна. Из-за этого правила злоумышленник с менее чем 50% пространства и без преимущества VDF будет иметь проблемы с заработком больше, чем его справедливая доля, поскольку он должен быть удачливым и создать больше блоков цепочки вознаграждений, чем подленная цепочка. Более того, фармеры только формят на вызовах, которые соответствуют самой тяжелой цепочке.
И скорость VDF, и общий объем пространства важны для веса, и их изменение может вызвать корректировку сложности. Если количество пространства увеличивается, будет создано более 32 блоков на слот, поэтому сложность должна быть увеличена. Если скорость сетевого VDF увеличивается, больше, чем 32 блоков создаются каждые 10 минут, и, следовательно, сложность (и итерации sub-слотов) должны быть увеличены.
Однако фармер с эксклюзивным доступом к немного более быстрому VDF не может легко получить больше вознаграждение, чем фермер с VDF с нормальной скоростью. Если злоумышленник пытается осиротить один из блоков в цепочке, наличие более быстрого VDF не поможет, поскольку в цепочке злоумышленника будет меньше блоков (и, следовательно, меньший вес). Фармеры должны подписать блок, на котором они строят, и они будут строить только на вершине цепочки с наибольшим весом.
Однако скорость VDF вступает в игру, когда атакующий хочет начать атаку с 51%. В этом случае атакующий фармер может использовать VDF, чтобы создать полностью альтернативную цепочку без подленных блоков и обогнать подленную цепочку.
Фольяж (Листва)
На приведенных выше диаграммах фармерам некуда указывать свое вознаграждение, так как все блоки канонические. Фармеры не имеют права голоса в том, как строится их блок, поскольку они должны использовать точное доказательство пространства, VDF и подписи, которые указаны. Чтобы включить в систему вознаграждения за фармерство, а также транзакции, мы должны ввести дополнительный компонент блоков, называемый листвой. До сих пор мы обсуждали компонент «ветка».
Ветка (Trunk): компонент блоков и цепочки блоков, который включает в себя VDF, доказательства наличия пространства, подписи PoS, запросы и предыдущие блоки ветки, и является полностью каноническим. Ветка никогда не относится к цепочке фольяж
Листва: компонент блоков и цепочки блоков, который включает в себя указание того, куда должно идти вознаграждение, какие транзакции должны быть включены и каков предыдущий блок листвы. Это зависит от фармера, и его можно разграничить, поэтому его нельзя использовать в качестве исходных данных для решения проблем.
Реорганизация: — это когда вид узла изменяется на пике, так что старое представление содержит блок, который не включен в новое представление (некоторые блоки меняются местами). Возможны реорганизации ветки и фольяжа, но на практике это случается редко.
На рисунке 11 ниже мы видим, что фольяж добавляется к блокам, чтобы образовалась дополнительная цепочка. Этот фольяж включает в себя хеш предыдущего фольяжа, хеш блока вознаграждения и подпись. Эти указатели фольяжа отделены от цепочки ветки и не являются каноническими. То есть фармеры теоретически могут реорганизовать фольяж, при которой фольяж заменяется, но используется та же самая ветка (свидетельство пространства и времени). Чтобы этого избежать, честные фармеры создают только один блок фольяжа на блок. Как только честный фармер добавил блок фольяжа, фальяж становится невозможно реорганизовать за пределы этой высоты с тем же PoSpace, так как этот фармер не будет повторно подписывать с тем же PoSpace.
Кроме того, такие блоки, как B3, которые идут параллельно другому блоку фольяжа (B2), не должны подписывать предыдущий блок фольяжа, поскольку у них не обязательно достаточно времени, чтобы увидеть его. Под «идущими параллельно» мы подразумеваем, что сигнальная точка второго блока находится перед точкой инфузии первого блока. Красные стрелки на схеме представляют собой указатель фольяжа, подписанный ключом графика для доказательства наличия пространства в этом блоке. Серые стрелки представляют собой хеш-указатель, который не подписан ключом графика (поэтому серая стрелка в B3 может быть заменена, если B2 изменяется или удерживается). Это предотвращает атаки, в которых B2 изменяет свой блок и вынуждает B3 реорганизоваться.
Блоки с красными указателями также могут создавать транзакции и поэтому называются блоками транзакций. Блок является блоком транзакции тогда и только тогда, когда он является первым блоком, сигнальная точка которого возникает после вливания предыдущего блока транзакции. sp3 предшествует B2 (блок транзакции и предыдущий блок B3), поэтому B3 не может быть блоком транзакции. Красные стрелки обеспечивают безопасность при закапывании блоков фольяжа, а серые стрелки - нет. Назначение серых стрелок - сохранить связанный список в фольяже и упростить реализацию. Однако блоки с серыми стрелками, указывающими на них, попадают в следующий-следующий блок.
Рисунок 11: Блоки и блоки фольяжа. Блоки содержат транзакции и имеют красные указатели (указатели на последний блок). Обратите внимание, что начало вспомогательного слота также является указателем.
Хеш блока - это хеш всего фольяжа и блока ветки. Реорги работают с хешами блоков. Даже если мы видим цепочку с одинаковыми доказательствами пространства и времени, пока фольяж разный, блоки будут разными. Обратите внимание, что оба фармера (B2 и B3) могут иметь возможность создать блок, поэтому оба должны предоставить подписанный указатель и транзакции. Однако любой блок транзакции также может быть включен как обычный блок, а поскольку B2 и B3 работают параллельно, только один из них может создать блок транзакции.
Хотя все блоки по-прежнему выбирают пазл хеши, куда направляется их вознаграждение, эти транзакции не включаются в цепочку блоков до следующего блока транзакции.
Для основной сети chia каждые 600 секунд будет происходить 32 блока, при среднем времени блока 18,75 секунды. Будет 64 указателя, поэтому минимальное время между блоками составляет 3 * 600/64 = 28,125 секунды. Таким образом, среднее время блокировки транзакции составляет 46,875 секунды.
Эпохи и регулировка сложности
Sub эпоха: Sub-эпоха N начинается когда sub-эпоха N-1 заканчивается (исключение для нулевой sub-эпохи), и заканчивается в конце первого слота в который с момента возникновения было включено 384 * (N+1) блоков.
Эпоха: Эпоха N начинается когда эпоха N-1 заканчивается (исключение 0я эпоха), и заканчивается в конце первого слота в который с момента возникновения было включено 4608 * (N + 1) блоков.
Сложность: константа, которая масштабирует количество итераций для данного доказательства пространства. Итерации рассчитываются как сложность / качество.
Каждые 4608 блоков активируется регулировка сложности. Это изменяет два параметра: параметр slot_iterations и параметр сложности.
Параметр sub_слот интеграций сбрасывается, поэтому для 300-секундного слота требуется много итераций, близких к слотам интеграции. Сброс выполняется с использованием значений из последней эпохи, чтобы точно приблизить количество итераций в секунду.
Для эпохи пусть эпоха * обозначает слегка сдвинутый период, когда эпоха * начинается с последнего блока, который был добавлен до начала эпохи, и заканчивается последним блоком, который был добавлен в эпоху. Значения t1, i1 и w1 обозначают метку времени итераций с момента создания и вес с момента создания в начале эпохи *, (t2, i2, w2) - это значения в конце эпохи *.
То есть дельта общего количества итераций от начала до конца эпохи, деленная на дельту временных меток, i2, представляет собой общее количество итераций точки вливания последнего блока в эпоху. i1 - это общее количество итераций точки вливания последнего блока в предыдущую эпоху. Итерации sub-слота - это общее количество итераций на sub-слот.
Обратите внимание, что мы берем итерации и время не точно в конце эпохи, а то что в последней точке инфузии блока в эпоху, причина просто в том, что у нас есть временные метки, доступные только тогда, когда блоки вливаются.
weight/sec of last epoch =(new weight - old weight)duration of last epoch
= w2 - w1 / t2-t1
new difficulty = weight/sec * target secondstarget number of blocks
= w2 - w1 / t2-t1 * (4608/64) * 3004608
= w2 - w1 / t2-t1 * 4.6875
Это можно изменить, чтобы использовать только одноэтажное подразделение:
new difficulty =floor (75 * (w2 - w1) 16 * (t2-t1))
Итерации sub-слота настраиваются таким образом, что каждый слот длится около 600 секунд. Сложность настраивается таким образом, что каждая задача получает в среднем 32 блока с меньшим количеством итераций, чем слоты интеграции. Важно отметить, что количество итераций VDF на слот не имеет значения для веса. То есть, если бы было два идентичных мира, в которых скорости VDF были равны, а пространство было равным, но параметр итераций sub-слота был в 2 раза выше в одном мире, то блокчейн с более высокими итерациями sub-слота получил бы вдвое больше блоков включается в каждый слот, но каждый слот занимает в два раза больше времени, поэтому вес, добавляемый к цепочке в секунду, одинаков в обоих случаях. Другой способ взглянуть на это заключается в том, что увеличение итераций sub-слота увеличивает количество блоков на слот, но также увеличивает продолжительность работы слотов и, таким образом, не влияет на вес в секунду.
Sub-эпоха
Как описано ранее, цепочка испытаний полностью отделена и не относится ни к чему в цепочке вознаграждения. Если эти цепочки навсегда останутся отдельными, злоумышленник с более быстрым VDF сможет заглянуть в далекое будущее и предсказать проблемы. Злоумышленник может создать по одному блоку на слот с ограниченным пространством, создавая, таким образом, целую цепочку вызовов. Это позволило бы им создавать плоты и мгновенно создавать доказательства наличия пространства для этих плотов, которые они выиграют в будущем, а затем удалять плолы (атака на дальние расстояния). Таким образом, они могут заполнить свою цепочку вознаграждений и увеличить свой вес.
Решение состоит в том, чтобы периодически (каждые 384 блока, что составляет в среднем 2 часа) вливать конец слота цепочки вознаграждений в цепочку задач. Это означает, что злоумышленник может выполнить атаку с переназначением только на несколько часов в будущее. Само построение графика занимает несколько часов, но даже если злоумышленник может мгновенно перенастроить график, стоимость атаки перенастройки перевесит преимущества. Мы вливаем не текущий результат цепочки вознаграждений, а вывод цепочки вознаграждений в конце предыдущей sub эпохи (2 часа назад).
Стоимость создания плота включает в себя электричество для расчета всех таблиц, оперативную память, необходимую для создания этого плота, и фиксированные затраты на инфраструктуру (пространство, электричество, охлаждение и т. д.). Предполагая наихудший сценарий сверхбыстрого VDF и мгновенного построения плоттинга ASIC, преимущества будут эквивалентны преимуществам хранения этого слота на жестком диске в течение нескольких часов. Понятно, что эта атака не стоит этого, и что хранение плотов намного дешевле (анализ ниже).
Вышеупомянутое объясняет, почему интервал sub эпох должен быть относительно низким. Но почему мы не можем еще больше сократить его до менее 2 часов, для дальнейшего сдерживания повторных атак? Причина в том, что всякий раз, когда неканонические данные вводятся в цепочку запросов, возникает возможность для измельчения. Это означает, что злоумышленник может выбрать включение или исключение блоков, чтобы управлять тем, какой вызов будет через 2 часа в будущем. Если это время слишком короткое, они могут получить небольшое преимущество в пространстве, если будут делать это чаще.
Вторая цель sub-эпох - действовать как контрольные точки в протоколе, подобном flyclient, описанному ниже, для повышения эффективности легких клиентов.
Верификация легкого клиента
Легкая поддержка клиентов - еще одно преимущество доказательства наличия пространства по сравнению с доказательством ставки, поскольку все доказательства могут быть объективно проверены криптографически и требуют контроля фактического ресурса в определенный момент времени.
Для легких клиентов, которые хотят быстро синхронизироваться с цепочкой (например, мобильные кошельки), полный узел может создать небольшое доказательство, которое может убедить легкого клиента в том, что вес цепочки близок к некоторому значению. Это называется доказательством веса. Наивно, легкий клиент может загрузить каждый блок и все необходимые доказательства и проверить их, но с таким большим количеством блоков это потребует большой пропускной способности и CPU.
Более эффективный метод основан на протоколе, подобном Flyclient [4]. Узел (тестировщик) отправляет все сводки по sub эпоху из точки разветвления, которые включают сброс сложности, легкому клиенту. На каждые 384 блока приходится только один блок, так что это может достигать лишь нескольких МБ данных. Узел также детерминированно производит выборку нескольких sub эпох на основании запроса последнего блока. Subэпохи могут быть выбраны пропорционально сложности в течение этой sub эпохи. Для выбранной sub эпохи легкий клиент загружает один из блоков цепочки вызовов (которые составляют примерно 1/32 всех блоков) и вычисляет средние итерации инфузии всех блоков вызовов в этой sub эпохе. Основываясь на этом времени, легкий клиент может экстраполировать, сколько блоков содержит цепочка вознаграждений. Например, если все блоки вызова происходят с очень маленькими итерациями (близко к началу слота), вероятно, в этом слоте много блоков. И наоборот, если итерации близки к середине слота, вероятно, есть только один блок на слот. Это позволяет легкому клиенту загружать только 1/32 блоков в каждый слот, но при этом получать хорошую оценку общего веса.
Кроме того, для легкого клиента необходимо полностью загрузить несколько последних sub эпох. Это добавляет небольшой объем данных, но не позволяет атакующему создавать небольшие разветвления в конце цепочки. Основное различие между этим протоколом и flyclient заключается в том, что блоки не привязаны к использованию деревьев Меркла, а вместо этого легкий клиент загружает весь список хеша subэпох из генезиса, гарантируя, что запрашиваемые sub эпохи включены в цепочку. Еще одно отличие состоит в том, что загружаются целые разделы, а не отдельные блоки.
Необходимо провести дополнительный анализ того, сколько sub эпох должно быть загружено, и каковы границы того, что подразумевает доказательство веса.
Пулинг
Пулинг в Чиа - спроектирован так, чтобы быть чрезвычайно простым и более децентрализованным, чем пул в биткойнах / эфириуме. В Чиа открытый ключ пула встроен в плоты, для предотвращения кражи вознаграждения из пула фармерам, участвующим более чем в одном пуле. Фармер загружает адрес пула вместе со своей подписью. Фармер периодически отправляет частичные данные для доказательства пространства, которое имеет менее чем T итераций, где T выбирается пулом.
Когда фармер выигрывает блок, они отправляют на рассмотрение подпись фармера и подпись пула. Комиссионные за транзакции вместе с вознаграждением за блок идут фармеру, а ⅞ вознаграждения за блок идут в пул. Причина предоставления части вознаграждения фармеру состоит в том, чтобы не стимулировать атаки, когда один пул атакует другой, «объединяя» их, но фактически не представляя доказательства победы. Это атака, которая может вывести из строя другой пул.
Это проще, потому что пулу не нужно ничего делать, кроме однократной публикации своей подписи на веб-сайте, сбора частичных данных и периодических выплат. Он более децентрализован, потому что блоки создаются фармерами, поэтому большие централизованные пулы мало контролируют сеть, и это увеличивает сопротивление цензуре транзакций.
Второй более сложный протокол пула позволит вам указать одноэлементный смарт-контракт, в котором будет храниться адрес пула. Затем плоты будут включать в себя хеш пазла смарт-контракта, позволяющий фармерам переключать пулы в любое время с задержкой. Недостатком этого протокола объединения является то, что для начала ведения фарминга требуется внутричейн-транзакция, и поэтому она не совсем лучше, чем первый протокол объединения.
Таймлорд алгоритм
Таймлорд отслеживает текущий пик, который включает в себя инфузионный блок на определенной высоте, и точки указателей, начиная с пика и далее. Таймлорд может получать новые блоки для наполнения, новые пики (блоки, которые уже наполнены) или новые точки указателей.
Как таймлорд решает, для каких задач нужно создавать доказательства времени, учитывая ограниченное количество доступных процессоров? В то время как ASIC, вероятно, будут развиваться в будущем, в настоящее время самые быстрые реализации VDF группы классов находятся на аппаратном обеспечении общего назначения, поскольку кажется, что VDF группы классов сложен для FPGA. Более того, даже после разработки ASIC важно, чтобы любой пользователь с CPU мог быть таймлордом, чтобы обеспечивать запасной вариант в случае, если таймлорд ASIC выйдет из строя или станет вредоносным и т.д.
В общем, таймлорды работают с самой тяжелой цепочкой. Они создают доказательства времени на указателях и транслируют их в сеть по мере их достижения. Они также вводят блоки так часто, как только могут. Когда таймлорд получает наполненный блок, который имеет больший вес, чем текущий пик, он немедленно переключается на него.
Таймлорды также запускают три цепочки VDF параллельно. Следовательно, для эффективного продвижения блокчейна необходимо как минимум 3 быстрых ядра CPU. Для создания доказательств с эффективной скоростью потребуются дополнительные ядра CPU, но они не должны быть такими быстрыми.
Если таймлорд получает вызов с меньшим весом, чем их текущий пик, он игнорирует его.
Если таймлорд получает точку вызова позже в текущей цепочке, безопаснее всего ее проигнорировать. Причина в том, что при переключении на точку, расположенную дальше в будущем, таймлорд может пропускать инфузию блоков и, таким образом, теряет допустимые блоки.
Если таймлорд получает блок для вливания, который запаздывает (мы уже достигли точки вызова, в которой блок должен был быть заполнен), мы игнорируем это, поскольку переключение на него позволит злоумышленникам удерживать блоки [TODO expand]. Поэтому основная операция таймлорда включает в себя сохранение кеша будущих блоков для внедрения, широковещательную передачу контрольных точек, когда они достигнуты, и вливание блоков, когда мы достигаем их контрольных точек.
Если таймлорд получает вызов с таким же весом, что и текущий пик, он выбирает незавершенный блок, который они видели первым (то есть блок, который еще не был наполнен), в отличие от выбора наполненного блока (пика), который они увидели первым. Это также препятствует задержки блоков.
Соответствующие атаки и контрмеры
51% (46%) атака:51% атак предполагает создание альтернативной цепочки, которая в конечном итоге достигает более высокого веса, чем подлинная цепочка, и вынуждает пользователей реорганизоваться. Классическая дальняя атака, которая также присутствует в системах доказательства работы, - это 51% атак. В 51% атак злоумышленник, владеющий 51% сетевого пространства, создает альтернативную цепочку и в конечном итоге ее достигает. Есть два основных различия между консенсусом Чиа и Доказательством работы: первое заключается в том, что злоумышленник может расширяться и фармить одновременно во многих цепочках. Во-вторых, если у злоумышленника самый быстрый VDF, он может получить дополнительное преимущество / ускорение в пространстве.
Расширение многих цепочекЕсли злоумышленник создает свою собственную частную цепочку, он может выбрать, какой блок будет включен в цепочку вызовов, и, следовательно, может попробовать множество различных вливаний, чтобы получить наилучшую возможную цепочку. Из-за того, что в среднем 32 блока с одним и тем же вызовом, злоумышленник может попробовать только около 32 различных комбинаций (какой блок включить в цепочку вызовов), и экспоненциальное разветвление попытки каждой из них даст небольшой прирост пространства для атакующего. (Имея 5 ПиБ, они могут притвориться, что у них 6 или 7 и т.д.). Это связано с тем, что альтернативные цепочки, которые проверяются, являются худшими и с меньшей вероятностью обгонят самую длинную. Это было проанализировано в [1].
Фактический объем пространства, необходимого для выполнения этой атаки (чтобы злоумышленник получил более тяжелую цепочку, чем остальная часть сети вместе взятых), составляет 46,3% из-за способности злоумышленника «пробовать» различные комбинации блоков, например, пропуская или не пропуская первый блок. Если было новое доказательство проблемы с пространством для каждого отдельного блока, злоумышленник может умножить свое пространство на коэффициент e = 2,718, где требуется только 27% для захвата сети. Установка количества блоков на 32 увеличивает необходимое пространство для атакующего до 46%.
Причина, по которой не следует увеличивать это значение больше 32, заключается в следующем: если мы увеличим количество блоков в 10-минутном слоте примерно до 200, то возможность для кого-то с немного более быстрым VDF отбросить других увеличится. Это потому, что время между блоками станет очень маленьким. С 32 блоками время между блоками составляет около 15-25 секунд, и для отбрасывания требуется гораздо более быстрый VDF.
Кроме того, Стэнфордская статья показывает, что увеличение количества блоков на вызов повышает безопасность очень медленно, поэтому небольшое увеличение этого числа не дает большой пользы.
Если злоумышленник будет управлять сложностью, он может изменить ее, чтобы получать меньше блоков вознаграждения на слот. Затем они могут либо включить, либо исключить каждый блок и экспоненциально расширять все цепочки одновременно, и они смогут умножить свое пространство на небольшой коэффициент [1]. Неясно, сильно ли выигрывает эта атака, так как атакующий должен изменить сложность, что требует некоторой потери веса. Однако, чтобы предотвратить эту атаку, необходимо создать не менее 16 блоков цепочки вознаграждений для включения блока вызова. Это увеличивает необходимое пространство для атакующего в худшем случае с 27% до 42%.
Более быстрый VDF и 46% пространства46% атака становится хуже, если VDF атакующего работает быстрее. Предположим, VDF атакующего в 2 раза быстрее. Тогда их цепочка сможет создавать проблемы и блоки в 2 раза быстрее, чем остальная часть сети, что означает, что они могут создавать «более тяжелую» цепочку с тем же объемом пространства.
Это необходимое пространство уменьшится с 46% до примерно 30% от общего сетевого пространства. 0,46 / 0,54 = 2x / (1-х). х = 0,30. Если у злоумышленника нет доступа к самому быстрому VDF, он не сможет получить преимущество в пространстве.
Чиа прострастно / глобальное пространство на жестком дискеЕсть опасения, что если в системе Chia недостаточно места по сравнению с доступным свободным пространством производителей жестких дисков или крупных компаний, то она будет уязвима для атак на 51%. Следовательно, чем больше места занимает система Chia, тем более безопасна сеть. Один из вероятных сценариев состоит в том, что требуется много места, что делает вознаграждение за ТБ довольно низким и недостаточно значительным, чтобы оправдать покупку дисков или удаление бизнес-данных. Кроме того, создание плота требует фиксированного количества времени и денег (по текущим расчетам в beta17, около 1 кВт/ч для k32 или около 10 центов, что составляет 1 доллар за терабайт).
100% атакаЕсли регулировка сложности запускалась каждые X слотов VDF, в отличие от каждых X блоков, это позволило бы совершить 100%-ную атаку, когда все фармеры вступают в сговор, чтобы постоянно уменьшать или увеличивать сложность. При нормальной работе на слот приходится 32 блока. При 100% атаке сложность регулируется таким образом, что сложность снижается на 2, так что на слот приходится 64 блока, а затем повышается на 4, так что в каждом слоте есть 16 блоков, чередующихся бесконечно. Это позволило бы фармерам зарабатывать в среднем 64 + 16/2 = 36 наград за блок за слот. Это причина для корректировки сложности в зависимости от количества блоков.
Атака с переносом на короткие дистанцииПлоттинг обычно занимает несколько часов (8 часов для k32 в beta 14 с одним ядром), но он очень распараллеливаемый, поэтому злоумышленники могут найти способы создать плоты после того, как вызов будет выпущен, а затем удалить плот, фактически имея возможность фармить, не сохраняя пространство постоянно. Скорее всего, для этого потребуется дорогостоящее специализированное оборудование с быстрой памятью, поскольку плот должен быть создан вовремя для инфузии (менее 30 секунд).
Если мы предположим наихудший сценарий, когда фармер сможет мгновенно создать плот, возникает вопрос: каковы затраты и какова польза от атаки? Стоимость - это стоимость электроэнергии, памяти, оборудования и инфраструктуры для создания этого плота. Стоимость создания 1 ТБ в настоящее время составляет порядка 1 доллара США в виде затрат на электроэнергию. Преимущество будет таким же, как и при хранении этого графика в течение 80 минут (интервал точки указателя умножается на постоянную фильтра плота). Это потому, что злоумышленник может выбрать плот, который проходит фильтр плота. Если предположить, что стоимость одного терабайта составляет 5 долларов США в год, то стоимость участка размером 1 ТБ для 80 минут составит 0,00094 доллара США. Поэтому с текущим плоттинг программным и аппаратным обеспечением, значительно дешевле хранить плоты, чем воссоздавать их.
Плот фильтр очень полезен для уменьшения количества операций поиска на диске, которые должны выполнять фармеры. При фильтре участка 512, вместо 7 операций чтения с диска на участок каждые 9 секунд, фармерам нужно выполнять только 7 операций чтения за каждые 80 минут. Константа плот фильтра обеспечивает злоумышленнику множитель при повторном построении плота, поэтому ее нельзя устанавливать слишком высоко. При константе плот фильтра 512, 1/512 плотов действительны для каждой задачи. Затем злоумышленник может создавать только плоты, которые проходят фильтр, поэтому нет необходимости создавать другие 511/512. Установка его на 512 дает множитель 512х и т. д.
Более быстрый VDF (но не атака 51%)Благодаря самому быстрому VDF в системе злоумышленник может более эффективно выполнить атаку 51%, то есть расширить свое пространство при фарминге в приватной цепочке. Если атакующий не достигает в общей сложности 51% пространства (с усилением VDF и расширением многих цепочек, как указано выше), полезность более быстрого VDF существенно снижается. Это связано с тем, что включение и исключение блоков не зависит от того, насколько быстро вы можете выполнить VDF, а вместо этого зависит от того, меньше ли оно, чем итераций sub-слота. Кроме того, злоумышленнику необходимо пространство для остальной части сети, чтобы продвигаться вперед, и, следовательно, он должен избавиться от проблем в сети.
В некоторых случаях, когда блоки расположены очень близко друг к другу, наличие более быстрого VDF может позволить злоумышленнику отбросить определенные блоки, хотя это не увеличивает вознаграждение в краткосрочной перспективе и несет риск подрыва сети в долгосрочной перспективе.
Эгоистичный фармингЭгоистичный фарминг - это атака, при которой злоумышленник собирает блоки в частном порядке и освобождает их только тогда, когда есть риск быть превзойденным подлинной цепочкой. В Накамото PoW это обеспечивает значительный выигрыш, потому что в любой момент, когда майнер опережает остальную часть сети, остальная часть сети тратит свою хеш-мощность на цепочку, которая не выиграет. В консенсусе Чиа это по-другому, из-за задержки в 30-40 секунд и того факта, что отброшенные блоки других фармеров не увеличивают вознаграждение.
Атака с целью подкупа фармераИнтересной атакой, исследованной [10], является атака подкупа, которая использует предсказуемость избранных «лидеров» в каждом слоте. Авторы анализируют доказательство цепочки ставок и утверждают, что, когда участники заранее знают, что они собираются выиграть, существует потенциальная атака с подкупом. Если участники заранее знали, какие слоты выиграют, каждый пользователь может уведомить злоумышленника о том, что они готовы участвовать в атаке, а если они достигнут определенного порога, они могут полностью реорганизовать цепочку (или отбросить тех, кто не участвует, цензура транзакции и т. д.). Эта атака НЕ требует для участия большей части пространства в сети; только победители за этот короткий период времени. Более того, его невозможно обнаружить, так как злоумышленник может создать обычную цепочку.
Эта проблема отсутствует в этой версии алгоритма консенсуса Chia. Эта проблема решается за счет снижения предсказуемости: каждый фармер не знает наверняка, соответствует ли его доказательство наличия пространства всем критериям, пока не появится указатель. Поэтому злоумышленник должен подкупить большую часть пространства, чтобы осуществить эту атаку.
Реорганизация фальяж атаки с целью подкупа фармераПоскольку блоки подписываются ключами PoSpace, фармер теоретически может подписывать несколько блоков с помощью одного и того же PoSpace на одинаковой высоте. Атака требует, чтобы злоумышленник подкупил фармеров определенной суммой средств, чтобы они подписали альтернативную цепочку. Если злоумышленник сможет убедить каждого фармера в N блоках подписать, он сможет отменить или изменить порядок любой транзакции в этих N блоках. Потенциально можно использовать доказательства мошенничества, но они не были выбраны, поскольку они допускают другие атаки и усложняют поведение.
Взамен этого решение заключается в том, чтобы просто ждать дольше. После 32 блоков
(приблизительно 10 минут) предположение о том, что по крайней мере один фермер
соблюдает протокол, а не двойное подписание, является разумным.
Если 54% не вступают в сговор (предположение о 46% устойчивости к атакам), вероятность отмены после 32 блоков составляет 1,8 * 10-13 = 0,00000000000018. Кроме того, эту атаку можно обнаружить, поэтому ее нелегко осуществить.
Каждый пользователь может выбрать свой собственный порог, для которого он принимает транзакцию / блок как окончательную. Например, в случаях, когда общее сетевое пространство внезапно падает, пользователи могут быть более осторожными и не считать транзакции окончательными, если существует еще одно разветвление, например, из-за разделения сети.
Освобождение блоков транзакций от комиссий за транзакцииБлоки транзакций отличаются от блоков без транзакций, поскольку они содержат комиссию за транзакцию. Они могут превосходить вознаграждение за блок. На момент написания (ноябрь 2020 г.) на пике хайпа мы видим 2 вознаграждения за блок eth с 8 комиссиями за блок. В Chia это будет более экстремальным, поскольку не каждый блок содержит транзакции. Это приводит к атакам, когда фармер, занявший 2-е место, игнорирует 1-е место в попытке выиграть блок транзакции. Если 2-й блок наступает менее чем через 30 секунд после 1-го, они не указывают предыдущий блок, и, таким образом, 2-е место не может отбросить 1-е. Третье место могло бы отбросить обоих, но по этой цепочке никто не пойдет, так как она короче.
Однако, если в течение 30 секунд после 1-го блока нет блоков, 2-й может отбросить 1-й, но им придется убедить следующий блок фармить в своей альтернативной цепочке. Более легкая атака была бы, если бы атакующий контролировал и 2-й, и 3-й, и в этом случае он мог бы игнорировать первую и при этом быть более продолжительным. Эти атаки-одиночки не позволяют злоумышленнику украсть вознаграждения, а позволяют злоумышленнику немного снизить сложность. Поскольку они носят весьма ситуационный характер и требуют большого пространства, попытка такой атаки, скорее всего, нанесет сети больше вреда, чем потенциальная выгода для атакующего.
Отбрасывание показателейСогласно консенсусу Chia, два конкурирующих блока примерно в одно и то же время могут быть включены в цепочку блоков параллельно, не зная друг о друге. (Хотя блоком может быть максимум один). Поскольку все блоки транзакций также являются блоками, они оба включаются в цепочку, в результате чего получается цепочка с более высоким весом. Это означает, что процент отброшенных показателей в Chia будет практически нулевым если предположить низкую задержку сети. Если сетевая задержка превышает задержку инфузии (30-40 секунд), то отброшенный блок почти гарантирован, так что это скорее пошаговая функция. Это контрастирует с Nakamoto-PoW, в котором процент отбрасывания данных высок, если есть задержка в сети, и плавно уменьшается по мере улучшения состояния сети, но никогда не достигает нуля.
Безопасность
Безопасность аналогична другим консенсусным алгоритмам Накамото, таким как Биткойн. Гарантированной окончательности нет, но чем больше подтверждений у транзакции, тем она безопаснее. Для транзакции требуется определенное количество подтверждений, чтобы получатель предположил, что она не может быть изменена в соответствии <46% (* vdf преимущества). Поскольку фармеры теоретически могут подписывать несколько блоков на одной высоте, в Chia следует использовать больше подтверждений, чем в биткойнах. Однако при скорости 32 блока за 10 минут 6 подтверждений в биткойнах эквивалентны 192 в чиа, что более чем достаточно, чтобы считаться безопасным. Пока один из этих 192 фармеров ведет себя хорошо (без двойной подписи), эта транзакция не будет отменена.
Стоит отметить, что не требуется 54% подлинного фарминг пространства, но 54% не вступают в сговор. Фермеры, стремящиеся к прибыли, очень мало получают от отклонения протокола.
Существует дополнительное предположение, что по крайней мере один быстрый таймлорд должен быть подключен к не вступающей в сговор части сети, и что таймлорд злоумышленника не намного быстрее.
Живучесть
Живучесть системы консенсуса Чиа- одна из ее самых сильных сторон. Как и Биткойн, система Чиа продолжает развиваться, даже когда большая часть пространства отключается. Однако, в отличие от биткойна, система не сильно замедляется, когда это происходит, поскольку не все блоки являются блоками транзакций. Таким образом, пропускная способность транзакций не сильно упадет, если многие участники отключатся. Он будет продолжаться, даже если только 1 фармер находится в сети, хотя будет много пустых слотов, поскольку блок транзакции может быть создан только в том случае, если он ниже порога итераций sub-слота.
Конечно, в случае долгосрочного разделения сети последствия таковы, что должна быть выбрана одна цепочка, поэтому в этом случае могут быть большие реорганизации. Тем не менее, сеть выбирает более тяжелую цепочку, как и PoW.
Сравнение с консенсусными алгоритмами BFT
Доказательство свободного пространства можно также использовать в качестве механизма устойчивости к Sybil, чтобы запустить систему византийского консенсуса (k-соглашение). Filecoin и многие системы доказательства доли используют аспекты византийского консенсуса.
Плюсы и минусы использования Консенсуса Чиа Накамото против византийского консенсуса, которые варьируются от алгоритма к алгоритму:
- Намного проще
- Нет необходимости в регистрации
- Нет требований к масштабируемости (масштабируется до миллионов фармеров)
- Больше устойчивости к цензуре. Пока небольшая часть фермерского пространства не подвергается цензуре, в конечном итоге вы можете попасть в блокчейн
- Нет требований к живучести, потенциально меньше сетевых предположений
- Полностью объективный (узел может сравнить цепочку 1 и цепочку 2 и сразу узнать, какая из них тяжелее). Нет необходимости в контрольных точках с консенсусом ⅔
- Лучшая поддержка легких клиентов
- Без окончательности, только вероятность
- Необходимо дольше ждать подтверждения транзакции
- Меньше согласовано время блока и меньше пропускная способность транзакций
Сравнение с Накамото PoW
- Разные ресурсы. PoSpace устойчив к ASIC, поэтому любой может участвовать в фарминге. Более децентрализованный.
- Легкое объединение фарминга. Другие криптовалюты могут использовать тот же формат, и каждый может делиться пространством. Вероятно, верхний будет единственным безопасным, поскольку фармеры могут атаковать более мелких.
- Минимальное потребление энергии, так как только несколько узлов запускают VDF, и они не распараллеливаются. Очень низкая предельная стоимость для майнинга.
- Более согласованное время блока транзакций (один раз в ~ 1 минуту).
- Меньше подвержены эгоистичным атакам майнинга.
- Меньше отброщеных показателей и разветвлений, так как блоки можно включать параллельно.
- По-прежнему продвигается с той же скоростью при уменьшении пространства, поскольку только 1/16 блока включает транзакции. Консенсус Накамото PoW замедляется.
- Недостаток большего количества потенциальных атакующих (крупных компаний). Оборудование общего назначения, поэтому злоумышленники могут переключаться между фармингом, атакой и использованием для хранения данных.
- Ускорение VDF может дать преимущество в пространстве для атакующего сеть.
- Большая сложность из-за sub слотов и VDF, потенциально более криптографические предположения
Сравнение с доказательством доли владения (PoS)
Этот алгоритм консенсуса также можно использовать для доказательства доли владения, когда пространство фермеров заменяются стейкерами, которые владеют монетами в системе. Преимущество будет заключаться в возможности сократить (удалить долю людей), и у фармеров будет «свой интерес», но есть некоторые опасения, если используется доказательство доли владения. (+ означает преимущество использования пространства по сравнению с долей владения).
- Злоумышленник может передать свою долю кому-то другому, но разветвляет цепочку прямо перед передачей своей доли. В этой альтернативной цепочке злоумышленник по-прежнему имеет всю свою долю и, следовательно, может продвигать цепочку. Проблема «ничего не поставлено на карту» в PoStake отличается от PoSpace, поскольку для создания PoSpace требуется физический ресурс (место на жестком диске), а для создания PoS требуется только ключ.
- Атакующий может гарантировать свою долю, поставив свои вознаграждения (богатые становятся богаче), поскольку общее количество монет ограничено.
- Возможны ситуации, когда атакующий может использовать множество различных способов передачи ставки. Возможно, это можно смягчить, если потребуется длительный период времени, прежде чем ставка станет активной.
- Требуется регистрация, вы не можете участвовать в доказательстве владения ставки до тех пор, пока не зарегистрируетесь. Это снижает конфиденциальность и масштабируемость (сколько людей может делать ставки).
- Более высокий барьер для входа: залоговые депозиты и слэшинг затрудняют участие мелких пользователей. Слэшинг может быть огромным риском для участников сети. Централизованные хранители приводят к менее распределенному набору участников.
- Некоторые предположения [11] требуются для выполнения легкой клиентской синхронизации для подтверждения доли.
- Интерес: с PoStake консенсус может сократить долю людей, а также требует некоторых инвестиций в систему (зависимость от цены). В доказательстве доли владения жесткие диски можно использовать для других целей, и нет возможности «сокращать» оборудование людей.