Proof of History: алгоритм консенсуса для синхронизации времени

Среди десятков согласованных алгоритмов, используемых для управления блокчейном различных проектов, есть один алгоритм под названием Proof of History, решение, разработанное командой Project Solana для постоянного устранения проблем, связанных с достоверностью временных меток в распределенной сети.

Децентрализованные сети частично решили эту проблему, полагаясь на надежные, но централизованные сторонние решения для синхронизации. Например, Google Spanner использует atomic clocks, которые синхронизируются друг с другом и с различными центрами обработки данных.

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

Например, такие решения, как Hashgraph, решают эту проблему со средней меткой времени. Каждое сообщение, отображаемое сетью, подписывается и помечается объектом более высокого уровня. Это приводит к средней отметке времени синхронизации на основе всех подписанных и сертифицированных сообщений.

Однако это неэффективное решение, поскольку все сообщения должны собираться сетью и подписываться. Затем следует рассчитать среднюю временную метку и затем перераспределить в сети. Это система, которая слишком медленная.

И здесь вступает в действие алгоритм консенсуса «Proof of History».

Proof of History: алгоритм блокчейн для синхронизации времени

Вместо использования классической концепции временных меток можно доказать, что сообщение / событие произошло в определенное время после одного события, но перед другим.

Например, когда вы фотографируете обложку журнала, это создает доказательство того, что фотография была сделана после публикации этого журнала.

При помощи Proof of History можно создать запись, которая показывает, что определенное событие произошло в определенное время, до или после других событий, и все это без использования меток времени или сторонних систем синхронизации.

Это означает, что функция требует ряда последовательных шагов для оценки и получения уникального и надежного результата, который затем публикуется.

В Solana (проект разработавший Proof of History), используется функция, в которой используется система последовательного хеширования, устойчивая к предварительным изображениям (предварительно подготовленным изображениям хэшей).

Для этого выход операции становится входом следующей операции. Затем периодически записываются текущее количество, состояние и выходные данные.

В случае SHA256 этот процесс невозможно распараллелить без Brute Force атаки с использованием 2¹²⁸ ядер.

Вход

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

При добавлении входных данных все будущие выходы будут непредсказуемо меняться.

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

Это доказывает, что между двумя операциями прошло определенное время. Можно доказать, что данные были созданы до включения.

Обратная ссылка

Входные данные Proof of History могут содержать ссылки на предыдущие события Proof of History. Обратная ссылка может быть вставлена ​​как часть сообщения, подписанного подписью пользователя, что означает, что ее нельзя изменить без личного ключа пользователя.

Со ссылкой на пример журнала, это будет эквивалентно тому, как пользователь делает фотографию с журналом в руке.

Поскольку сообщение содержит хэш 0xdeadc0de, известно, что оно было сгенерировано после создания счетчика 510144806912. Затем сообщение вставляется обратно в последовательную функцию.

Итак, возвращаясь к примеру, как если бы была сделана фотография с журналом в руках, на следующий день журнал опубликует фотографию пользователя, держащего журнал.