Dudochkin Victor
Синхронизация
Быстрая и надежная синхронизация — главная причина, по которой Solana может достичь такой высокой пропускной способности. Традиционные блокчейны синхронизируются на больших фрагментах транзакций, называемых блоками. При синхронизации блоков транзакция не может быть обработана до тех пор, пока не истечет продолжительность, называемая «время блока». В консенсусе Proof of Work это время блока должно быть очень большим (~ 10 минут), чтобы свести к минимуму вероятность того, что несколько валидаторов создадут новый действительный блок одновременно. В консенсусе Proof of Stake такого ограничения нет, но без надежных временных меток валидатор не может определить порядок входящих блоков. Популярным обходным решением является пометка каждого блока временной меткой настенных часов. Из-за дрейфа часов и различий в сетевых задержках метка времени точна только в пределах часа или двух. Чтобы обойти обходной путь, эти системы удлиняют время блока, чтобы обеспечить разумную уверенность в том, что медианная метка времени в каждом блоке всегда увеличивается.
Солана использует совершенно другой подход, который она называет Proof of History или PoH. Узлы-лидеры «отмечают время» блоков с криптографическими доказательствами того, что с момента последнего доказательства прошло некоторое время. Все данные, хэшированные в доказательство, наверняка произошли до того, как доказательство было сгенерировано. Затем узел делится новым блоком с узлами-валидаторами, которые могут проверить эти доказательства. Блоки могут поступать к валидаторам в любом порядке или даже могут быть воспроизведены спустя годы. С такими надежными гарантиями синхронизации Solana может разбивать блоки на более мелкие пакеты транзакций, называемые записями. Записи передаются валидаторам в режиме реального времени, до того, как будет достигнут консенсус по блокам.
Технически Солана никогда не отправляет блок, но использует этот термин для описания последовательности записей, за которые голосуют валидаторы для достижения подтверждения. Таким образом, время подтверждения Соланы можно сравнить с блочными системами. Текущая реализация устанавливает время блока на 800 мс.
Что происходит под капотом, так это то, что записи передаются валидаторам так же быстро, как ведущий узел может объединить набор действительных транзакций в запись. Валидаторы обрабатывают эти записи задолго до того, как придет время голосовать за их действительность. При оптимистичной обработке транзакций фактически отсутствует задержка между временем получения последней записи и моментом, когда узел может голосовать. В случае, если консенсус не достигнут, узел просто откатывает свое состояние. Этот метод оптимистической обработки был представлен в 1981 году и получил название Оптимистический контроль параллелизма. Его можно применить к архитектуре блокчейна, где кластер голосует за хэш, представляющий полную книгу до некоторой блоковой высоты. В Solana это реализовано тривиально с использованием хеша PoH последней записи.
Отношение к VDF
Техника Proof of History была впервые описана для использования в блокчейне Соланой в ноябре 2017 года. В июне следующего года аналогичная техника была описана в Стэнфорде и названа [функция проверяемой задержки](https://eprint.iacr. org/2018/601.pdf) или VDF.
Желательным свойством VDF является очень быстрое время проверки. Подход Соланы к проверке функции задержки пропорционален времени, затраченному на ее создание. Разделенный на 4000-ядерный графический процессор, он достаточно быстр для нужд Соланы, но если вы спросите авторов упомянутой выше статьи, они могут сказать вам ([и имеют](https://github.com/solana-labs/ solana/issues/388)), что подход Соланы алгоритмически медленный и его не следует называть VDF. Мы утверждаем, что термин VDF должен представлять категорию проверяемых функций задержки, а не просто подмножество с определенными характеристиками производительности. Пока это не будет решено, Solana, скорее всего, продолжит использовать термин PoH для своего VDF для конкретного приложения.
Другое различие между PoH и VDF заключается в том, что VDF используется только для отслеживания продолжительности. Хэш-цепочка PoH, с другой стороны, включает в себя хэши любых данных, наблюдаемых приложением. Эти данные — палка о двух концах. С одной стороны, данные «доказывают историю» — данные наверняка существовали до хэшей после них. С другой стороны, это означает, что приложение может манипулировать цепочкой хеширования, изменяя время хеширования данных. Таким образом, цепочка PoH не может служить хорошим источником случайности, тогда как VDF без этих данных может. [Алгоритм вращения лидера] Соланы (synchronization.md#leader-rotation), например, получен только из height VDF, а не из его хэша на этой высоте.
Связь с механизмами консенсуса
Proof of History не является механизмом консенсуса, но он используется для улучшения производительности консенсуса Proof of Stake Соланы. Он также используется для повышения производительности протоколов плоскости данных.