Жизненный цикл транзакции celestia-app
Last updated
Last updated
Пользователи запрашивают у celestia-app сделать данные доступными, отправляя транзакции PayForBlobs. Каждая такая транзакция включает в себя идентификатор отправителя, данные, которые должны быть сделаны доступными (также называемые сообщением), размер данных, именованное пространство и подпись. Каждый производитель блоков объединяет несколько транзакций PayForBlobs в блок.
Перед тем, как предложить блок, производитель передает его в машину состояний через ABCI++, где каждая транзакция PayForBlobs разделяется на именованное сообщение (обозначается как Msg на рисунке ниже), т.е. данные вместе с идентификатором именованного пространства, и исполняемую транзакцию (обозначается как e-Tx на рисунке ниже), которая не содержит данных, а только обязательство, которое может быть использовано позже для доказательства того, что данные действительно были сделаны доступными.
Таким образом, данные блока состоят из данных, разделенных на именованные пространства и исполняемые транзакции. Обратите внимание, что только эти транзакции выполняются машиной состояний Celestia после фиксации блока.
Затем производитель блока добавляет в заголовок блока обязательство данных блока. Как описано на странице Слой доступности данных Celestia, обязательство — это корень Меркла из 4k промежуточных корней Меркла (т.е. по одному для каждой строки и столбца расширенной матрицы). Для вычисления этого обязательства производитель блока выполняет следующие операции:
Разделяет исполняемые транзакции и именованные данные на части. Каждая часть состоит из нескольких байтов, к которым предписывается именованное пространство. В этом случае исполняемые транзакции ассоциируются с зарезервированным именованным пространством.
Упорядочивает эти части в квадратной матрице (построчно). Обратите внимание, что части дополняются до следующей степени двойки. Получившийся квадрат размером k x k называется исходными данными.
Расширяет исходные данные до квадратной матрицы 2k x 2k с помощью двухмерной схемы кодирования Рида-Соломона, описанной выше. Расширенные части (т.е. содержащие данные для восстановления) ассоциируются с другим зарезервированным именованным пространством.
Вычисляет обязательство для каждой строки и столбца расширенной матрицы, используя описанные выше NMTs.
Таким образом, обязательство данных блока — это корень дерева Меркла с листьями, представляющими собой корни леса поддеревьев Меркла с именованными пространствами, по одному для каждой строки и столбца расширенной матрицы.
Чтобы расширить возможности подключения, узел celestia дополняет celestia-app отдельной сетью libp2p, т.е. так называемой сетью DA, которая обслуживает запросы DAS.
Легкие узлы подключаются к celestia-узлу в сети DA, просматривают расширенные заголовки блоков (т. е. заголовки блоков вместе с соответствующими метаданными DA, такими как промежуточные корни Меркла), и выполняют DAS на полученных заголовках (т. е. запрашивают случайные части данных).
Заметим, что, хотя это и рекомендуется, выполнение DAS необязательно – легкие узлы могут просто доверять тому, что данные, соответствующие обязательствам в заголовках блоков, действительно были предоставлены уровнем Celestia DA. Кроме того, легкие узлы также могут отправлять транзакции в celestia-app, т.е. транзакции PayForBlobs.
Во время выполнения DAS для заголовка блока каждый легкий узел запрашивает у узлов Celestia несколько случайных частей данных из расширенной матрицы и соответствующие доказательства Меркла. Если все запросы успешны, то легкий узел принимает заголовок блока как действительный (с точки зрения DA).
Если хотя бы один из запросов неудачен (т.е. либо часть данных не получена, либо доказательство Меркла недействительно), то легкий узел отклоняет заголовок блока и повторяет попытку позже. Повторная попытка необходима для борьбы с ложноотрицательными результатами, т. е. когда заголовки блоков отклоняются, хотя данные блока доступны. Это может произойти, например, из-за перегрузки сети.
Альтернативно, легкие узлы могут принять заголовок блока, хотя данные недоступны, т.е. получить ложное срабатывание. Это возможно, так как свойство надежности (т.е. если честный легкий узел принимает блок как доступный, то хотя бы один честный полный узел в конечном итоге будет иметь все данные блока) вероятностно гарантируется (для получения более подробной информации ознакомьтесь с оригинальной статьей).
Путем точной настройки параметров Celestia (например, количества частей данных, тестируемых каждым легким узлом) вероятность ложных срабатываний может быть достаточно снижена, чтобы у производителей блоков не было стимула скрывать данные блока.
