Механизмы верификации в блокчейне

Как узнать о прошлых событиях на #blockchain? Вот 1️⃣0️⃣1️⃣ механизм верификации блокчейна 🤓.

Накопленные в прошлом события на блокчейне довольно важно знать. Они показывают свидетельства транзакций. Обратите внимание, что события и состояния блокчейна обрабатываются по-разному в разных цепочках⛓️.

Например, в Биткойне, если вы хотите узнать свой последний баланс, вы будете смотреть на прошлые события (еще не потраченные UTXO). Мы глубоко погружаемся в блокчейн-модели транзакций здесь.

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

Решение заключается в принципе: проверяй, а не доверяй. Блокчейн устроен таким образом, что любой пользователь может запустить "полный узел", чтобы проверить все в соответствии с правилами консенсуса. Полный узел обладает двумя важными свойствами 👇

A) Валидность: что блокчейн, которому соответствует полный узел, использует те же правила консенсуса.

B) Каноничность: все полные узлы в сети имеют единообразное представление о генезисной цепочке блоков. Другими словами, их блокчейны являются префиксами друг друга.

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

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

Одним из решений является так называемый "легкий клиент", который хранит минимальные данные о блокчейне, полагаясь на полные узлы для полных данных блокчейна (но вам нужно убедиться, что полные узлы честны 😇).

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

Хэш-функция:

1. уникальна: даже изменение одного бита приведет к совершенно другому хэшу (коллизии хэшей редки);
2. необратима: хэш-функция практически односторонняя: ее нельзя отменить.

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

Разумное решение, предложенное Биткойном, заключается в использовании дерева хэшей транзакций, так что легкому клиенту нужно хранить только корень хэша всего дерева транзакций.

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

Таким образом, при использовании дерева Меркла легкие клиенты хранят цепочку заголовков блоков (а не данные всего блока) и могут проверить включение транзакции, если предоставлено краткое доказательство Меркла. Дерево Меркла выглядит следующим образом:

Чтобы проверить, что транзакция TD включен в блок, вы берете корневой хэш (HABCDEFGH), запрашиваете сеть о HD, и она возвращает HC, HAB и HEFGH. Дерево Меркла проверяет, что все учтено с помощью этих трех хэшей и что HD (единственный отсутствующий хэш) должен присутствовать в данных.

Поздравляю. Теперь вы эксперт в верификации блокчейна 🎉 Следующий уровень - это то, как информация перемещается между блокчейнами, но это уже для другого #ZetaED.