Перейти к содержанию
Financial Context Wiki

Доказательство История: записанный порядок, тики, слоты и границы консенсуса.

Proof of History — это последовательные часы хеш-цепочки Solana: они позволяют проверить записанный порядок и число вычислений, но сами по себе не доказывают реальное время, справедливость порядка поступления транзакций, выбор форка или финальность.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Прямой ответ

Доказательство истории, или PoH, — это криптографические часы Solana и структура данных, упорядочивающая реестр. Производитель неоднократно применяет хеш-функцию, так что каждый вывод зависит от предыдущего вывода, периодически записывает счетчики и состояния и смешивает данные, полученные из транзакции, в цепочку. Верификатор может пересчитать эти переходы и подтвердить порядок, записанный этой конкретной цепочкой.

PoH не является автономным алгоритмом консенсуса. Он не выбирает канонический форк, не предоставляет соглашение с взвешиванием долей, не завершает блоки и не доказывает, что транзакция достигла сети в определенное время. Solana сочетает в себе часы с запланированными лидерами, выполнением транзакций, голосованием валидаторов, выбором вилки и блокировкой в ​​стиле Tower BFT. Каждая из двух вилок может содержать внутренне действительные последовательности PoH; Правила консенсуса определяют, какой истории следует сеть.

Узкая гарантия имеет значение. Если запись фиксирует данные d после состояния h2, то более позднее состояние h3 = H(h2 || d) не может быть вычислено без этого фиксации. Это показывает, что d был доступен генератору до h3, и фиксирует его положение относительно более поздних выходов. Он не показывает, когда каждый валидатор получил d, включил ли лидер транзакции в порядок поступления, описывает ли d истинное внешнее событие или стала ли запись канонической.

Генерация является последовательной, поскольку следующий ввод неизвестен, пока не существует предыдущий хэш. Опубликованные граничные состояния позволяют верификаторам параллельно воспроизводить отдельные ограниченные сегменты, но совокупная работа по хэшированию остается. По этой причине PoH часто сравнивают с проверяемой функцией задержки, в то время как собственное объяснение Tower BFT Solana называет это свободным использованием этого термина; формальный VDF обычно имеет интерфейс оценки и проверки, проверка которого эффективна по сравнению с последовательной оценкой.

Как анализировать подтверждение истории

  1. Исправить сетевой и программный контекст. Запишите сеть, хеш происхождения, слот, эпоху, Agave или другое версия клиента и время наблюдения. Считайте активные значения, такие как hashes_per_tick, ticks_per_slot и ns_per_slot; не импортируйте константы из старой статьи или другого кластера.
  2. Восстановите хеш-цепочку. Начните с состояния доверенного предшественника и проверьте num_hashes каждой записи, получившийся хэш и список транзакций. В реализации записи Agave идентификатор записи зависит от предыдущей записи и, при наличии транзакций, хэша, полученного из их подписей.
  3. Проверка тиков и размещения слотов. Проверьте записи тиков, ожидаемое количество хэшей, высоту тактов и максимальную высоту тактов на соответствие правилам банка и регистратора. Регистратор отображает высоту такта в слоте, используя настроенный ticks_per_slot; слоты представляют собой протокольные интервалы, а не независимые данные внешних часов.
  4. Отличайте включение от поступления. Обязательство доказывает, что входные данные были известны не позднее, чем они были вставлены в эту последовательность. Чтобы получить нижнюю границу, определите подписанную обратную ссылку на предыдущее состояние PoH. Ни одна граница не подтверждает глобальный порядок первого просмотра, справедливость мемпула или надежную временную метку UTC.
  5. Отдельная генерация от проверки. Измерьте последовательное производство в одной цепочке зависимостей, затем измерьте воспроизведение, используя границы аутентифицированного сегмента и доступные ядра. Сообщайте об общих хэшах, задержке критического пути, совокупной работе верификатора и предположениях о граничных данных, а не просто говорите, что проверка «быстрая».
  6. Проследите путь к консенсусу. Определите назначенного лидера, состояние Bank, голоса, блокировки, правило выбора форка, укоренённое или финализированное состояние и уровень подтверждения. Действительная цепочка PoH всё равно может принадлежать проигравшему форку, а более длинный счётчик сам по себе не является сертификатом консенсуса.
  7. Уделяйте внимание состязательным и эксплуатационным случаям. Двусмысленность лидера теста, пропуск транзакций и переупорядочение, пропущенные слоты, разделы, более быстрое или неправильно откалиброванное оборудование, недопустимое количество тиков, задержки воспроизведение, недоступность реестра, расхождение клиентов и коррелированный контроль оператора или инфраструктуры.

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

Работающие примеры

1. Вставка данных фиксирует записанную позицию

Рассмотрим h1 = H(h0), затем h2 = H(h1). Производитель вставляет полученное из транзакции обязательство d и вычисляет h3 = H(h2 || d), за которым следует h4 = H(h3). Любой, кто воспроизводит одни и те же операции, может убедиться, что записанная цепочка фиксирует d между h2 и h3 и что h4 зависит от результата.

Утверждение верхней границы является узким: производитель знал d до вычисления h3. Если сама подписанная транзакция ссылается на h1, верификатор также может показать, что она была сформирована после знания этого более раннего состояния, при условии проверки подписи и происхождения. Без такой обратной ссылки PoH сам по себе не предоставляет нижней границы. Ни один из случаев не доказывает, когда другой узел впервые получил транзакцию.

2. Воспроизведение сегмента уменьшает задержку, а не совокупную работу.

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

В совокупности верификаторы по-прежнему выполняют 1 000 000 хэшей; контрольные точки предоставляют независимые стартовые состояния, но не превращают цепочку в краткое доказательство. Производительность зависит от оборудования, планирования, движения памяти и уверенности в границах. Вот почему параллельное воспроизведение PoH не должно автоматически описываться как эффективный алгоритм проверки каждой формальной конструкции VDF.

3. Арифметика тиков и слотов зависит от конфигурации

Предположим, что это иллюстративная конфигурация с hashes_per_tick = 100,000 и ticks_per_slot = 8. Полностью хешированный слот затем содержит хэши 100,000 * 8 = 800,000 с границами тиков после каждого настроенного интервала. Изменение любого параметра меняет сопоставление; этот пример не является текущей константой основной сети.

Agave также поддерживает конфигурации, которые не описываются этим упрощённым умножением. Рецензент должен получить фактические поля Bank и проверить записи по правилам программного клиента. Перевод слота или счётчика в секунды зависит также от калибровки целевой длительности и наблюдаемого исполнения, а не только от криптографической проверки.

4. Записанный порядок не равен порядку поступления или финальности

Предположим, транзакция A достигает лидера раньше транзакции B, но лидер записывает B около 300 000, а A около 450 000. Действительный PoH доказывает, что B предшествует A в этой созданной последовательности. Это не доказывает, что Б прибыл первым, что порядок был справедливым или что другой лидер соблюдал тот же порядок.

Теперь предположим, что раздел создает вилку X и вилку Y, каждая из которых имеет допустимую последовательность. Проверка PoH может отклонять некорректные записи в любом из ответвлений, но не выбирает X или Y. Расписание лидера, взвешенные по ставкам голоса, локауты, выбор вилки и запрошенный уровень обязательств определяют консенсусный результат; приложения не должны заменять счетчик PoH для подтверждения или доказательства окончательности.

Риски и ошибки проверки

Криптографические ошибки и ошибки синхронизации

  • Вызов PoH надежными настенными часами или независимое утверждение хеш-счета доказывает UTC timestamp.
  • Утверждение о включении транзакции подтверждает время получения всей сети, порядок первого просмотра или достоверность внешних данных.
  • Предположение о последовательной генерации не позволяет производителю скрывать, упускать или выбирать, когда вставлять известные данные.
  • Рассматривать только устойчивость к коллизиям как полную границу скорости оборудования, отклонений калибровки или отклонений реализации.
  • Описание воспроизведения параллельного сегмента как нулевой работы или как краткое доказательство без подсчета совокупных хэшей.
  • Вызов PoH формальным VDF без указания конструкции, интерфейса доказательства и сравниваемых предположений проверки.
  • Доверие к границам контрольных точек, хэшам-предшественникам или загруженным сегментам реестра без аутентификации их происхождение.

Консенсус и ошибки протокола

  • Вызов консенсуса PoH, доказательства доли, Tower BFT, выборов лидера, выбора вилки и окончательности - один и тот же механизм.
  • Предположение, что действительная последовательность с наибольшим количеством очков должна быть канонической без изучения голосов и состояние выбора вилки.
  • Обработка локально воспроизводимой записи как подтвержденной, корневой или завершенной без проверки запрошенной семантики фиксации.
  • Использование исторических значений hashes_per_tick, ticks_per_slot или длительности слота в качестве универсальных текущих констант.
  • Игнорирование пропущенных слотов, лидера вращение, разделы, двусмысленность и различия версий клиента при восстановлении порядка.
  • Сравнение счетчиков несвязанных вилок или начальных состояний, как если бы они принадлежали к одной аутентифицированной последовательности.
  • Предполагая, что недавний хэш блока транзакции является просто временной меткой настенных часов, а не контекстом достоверности протокола.

Ошибки операций, производительности и контроля

  • Сравнительное тестирование только генерации хэша, игнорируя выполнение, проверку подписи, воспроизведение, пропускную способность и хранилище.
  • Приравнивание теоретического параллелизма сегментов к наблюдаемому догоне валидатора при CPU, I/O и конфликту памяти.
  • Игнорирование ошибок проверки тиков, зависаний регистратора, задержек в банковских операциях, пробелов в реестре, доверия к моментальным снимкам и поврежденного состояния.
  • Подсчет идентификаторов валидаторов как независимых, когда клиент, хостинг, сеть, ведущая инфраструктура или элементы управления являются общими.
  • Предполагая, что более быстрое оборудование устраняет задержку в сети, потерю пакетов, цензуру, риск отказа в обслуживании или концентрации ставок.
  • Представление продолжительности целевого слота, оценки пропускной способности или старого эталонного показателя в качестве гарантии уровня обслуживания.

Распространенные заблуждения

  • PoH — это полный алгоритм консенсуса Solana. PoH предоставляет проверяемую записанную последовательность; голосование валидатора, блокировки, выбор вилки и другие правила консенсуса определяют историю, которой следует сеть.
  • PoH доказывает точное реальное время каждой транзакции. Он доказывает зависимость и количество в аутентифицированной последовательности; сопоставление этой последовательности с гражданским временем требует настройки и внешних наблюдений.
  • PoH гарантирует справедливый порядок транзакций. Лидер может выбирать, задерживать, переупорядочивать или пропускать входные данные в рамках ограничений протокола и ресурсов; PoH делает проверяемым только итоговый записанный порядок.
  • PoH — это майнинг с доказательством выполнения работы под другим названием. Оба используют хеширование, но основная роль PoH — это последовательные часы, а не открытая параллельная гонка, победитель которой выбирает работу цепочка.
  • Любая допустимая последовательность PoH является окончательной. Каждая из конкурирующих вилок может быть внутренне допустимой; подтверждение и окончательность требуют консенсуса сети.

Связанные темы

Источники

Навигация

Поиск по вики...