Перейти к основному контенту

Структура блока: как упаковываются и связываются данные?

Теперь, когда мы знаем, как сеть достигает консенсуса относительно того, «кто ведет реестр», давайте углубимся в сам «реестр» — «блок» — чтобы понять, как данные искусно упаковываются и связываются, создавая неразрывную цепочку доверия.

1.3 Структура блока: как упаковываются и связываются данные?

Блоки объединяют многочисленные транзакции в «заголовки блоков» и «тела блоков», связывая их от начала до конца хеш-цепочками для формирования неизменяемого реестра.

Представьте, что вы пишете совместную историческую книгу. Каждая страница (блок) записывает все значимые события (транзакции) за последние десять минут. Чтобы эта книга была достоверной и защищенной от подделок, мы разработали сложную структуру для каждой страницы.

Два основных компонента блока​

Каждый блок состоит из двух основных частей:

  1. Заголовок блока Он действует как «карточка-указатель» или «обложка» блока, суммируя метаданные блока. Он не перечисляет конкретные транзакции, но предоставляет компактную версию этой информации. Ключевые поля включают:
  • previous_hash: Это важнейшее поле содержит хеш-значение предыдущего заголовка блока. Оно действует как цепочка, прочно «связывая» текущий блок с предыдущим.
  • merkle_root: Это «цифровой отпечаток» всех данных транзакций в блоке. Генерируется с помощью алгоритма дерева Меркла, уникально и компактно представляет все транзакции. Любое незначительное изменение в транзакции резко изменяет это корневое значение.
  • timestamp: Отмечает приблизительное время создания блока.
  • difficulty / target: В PoW-цепочках это указывает на сложность «майнинга». Майнеры должны найти хеш-значение ниже этого целевого показателя.
  • nonce: «Счетчик», который майнеры могут регулировать в PoW. Повторно изменяя Nonce, майнеры стремятся вычислить хеш заголовка блока, соответствующий целевой сложности.
  1. Тело блока Это «текст» блока, содержащий все конкретные данные, упакованные в этот блок, в основном список транзакций. Каждая транзакция представляет собой сложную структуру данных, обычно включающую такие детали, как отправитель, получатель, сумма и цифровая подпись. Тело блока значительно больше заголовка блока.

Дерево Меркла: криптографическое сжатие для пакетной верификации​

Если бы вы хотели проверить, существует ли определенное предложение в толстой книге, стали бы вы читать ее от корки до корки? Дерево Меркла предлагает более эффективный способ верификации.

Его построение похоже на турнир на выбывание:

  1. Сначала вычисляется хеш-значение каждой транзакции в теле блока.
  2. Затем хеш-значения двух соседних транзакций объединяются и хешируются снова для генерации хеш-узла верхнего уровня.
  3. Этот процесс попарного объединения и хеширования повторяется до тех пор, пока не останется одно уникальное хеш-значение. Этот верхний хеш является merkle_root.

Преимущества дерева Меркла:

  • Эффективная верификация: Для доказательства существования конкретной транзакции в этом блоке вам не нужно загружать все тело блока (которое может содержать тысячи транзакций). Вам нужна только сама транзакция, корень дерева Меркла и несколько «соседних» хеш-узлов на пути от транзакции к корню дерева (длина этого пути логарифмическая, т.е. log_2(n)).
  • Поддержка легких узлов: Это позволяет использовать «легкие кошельки» или узлы «упрощенной проверки платежей» (SPV). Эти устройства (например, мобильные кошельки) имеют ограниченное хранилище и должны загружать только все заголовки блоков, чтобы быстро и безопасно проверить, были ли подтверждены связанные с ними транзакции, без хранения полной истории транзакций.

Хеш-цепочка: «Цифровая печать» против подделки​

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

Каждый заголовок блока включает хеш-значение предыдущего заголовка блока. Это означает, что идентичность блока n (его хеш-значение) определяется его содержимым и идентичностью блока n-1. Идентичность блока n-1 определяется его содержимым и блоком n-2, и так далее, вплоть до генезис-блока.

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

  1. Они изменяют транзакцию, что приводит к изменению merkle_root блока i.
  2. Изменение merkle_root изменяет хеш заголовка блока i.
  3. Поскольку поле previous_hash блока i+1 записывает старый, правильный хеш блока i, эта связь теперь «разорвана». Чтобы восстановить цепочку, злоумышленник должен изменить поле previous_hash блока i+1.
  4. Но это изменение изменяет хеш заголовка блока i+1, что вынуждает вносить изменения в блок i+2...
  5. Злоумышленник должен пересчитать все блоки от блока i до последнего блока.

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

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

Процесс упаковки данных (на примере PoW)​

  1. Сбор: Узлы-майнеры собирают большое количество неподтвержденных транзакций из «пула транзакций» сети.
  2. Генерация корня дерева: Вычисляют хеш всех выбранных транзакций и строят дерево Меркла для получения уникального merkle_root.
  3. Сборка заголовка блока: Собирают merkle_root, previous_hash и другие поля в заголовок блока и устанавливают начальное значение nonce.
  4. «Майнинг»: Непрерывно итерируют nonce (0, 1, 2, 3...) и многократно вычисляют хеш-значение всего заголовка блока до тех пор, пока не найдут хеш-решение, меньшее текущей целевой сложности.
  5. Трансляция: Как только решение найдено, майнер немедленно транслирует этот вновь обнаруженный блок всей сети. При его получении другие узлы проверят его валидность (проверят правильность хеш-решения, законность транзакций и т.д.). После проверки блок добавляется в конец их локального блокчейна.

Компромиссы между безопасностью, пропускной способностью и производительностью​

Дизайн блоков включает несколько компромиссов:

  • Размер блока: Известное ограничение размера блока Биткойна в 1 МБ гарантирует быструю передачу блоков по глобальной сети, снижая риск форков. Ethereum, однако, использует более гибкий механизм «Gas Limit», позволяющий динамически регулировать пропускную способность блока в зависимости от потребностей сети.
  • Интервал между блоками: Интервал между блоками Биткойна составляет около 10 минут, в то время как у Ethereum — около 12 секунд. Более короткое время блока может увеличить TPS (транзакций в секунду), но также повышает вероятность «осиротевших блоков» (когда два майнера почти одновременно производят блоки), создавая нагрузку на синхронизацию сети.
  • Данные свидетелей и сжатие: Чтобы вместить больше транзакций без значительного увеличения размера блока, сообщество разработало инновационные решения, такие как SegWit (Segregated Witness) и EIP-4844 (Proto-Danksharding), которые перемещают некоторые данные (например, подписи) из основной структуры транзакций или вводят специальные «блобы» данных, эффективно снижая скорость расширения данных в цепочке без нарушения основной структуры.

🤔 Упражнения для читателей​

  1. Используйте Blockchair.com или аналогичный обозреватель блоков, чтобы случайно выбрать блок Биткойна. Найдите и запишите его merkle_root. Затем перейдите к любой транзакции и попробуйте понять, как сайт отображает путь «доказательства Меркла» (Merkle Proof) для этой транзакции.
  2. На бумаге или в документе представьте простой блок, содержащий три транзакции: «A->B 10 USD», «C->D 5 USD», «E->F 20 USD». Если вы измените первую транзакцию на «A->B 11 USD», подумайте, как это повлияет на корень дерева Меркла и, следовательно, на хеш заголовка блока. Почему в результате вся последующая цепочка будет «аннулирована»?

📚 Дополнительное чтение​

  • «Деревья Меркла и эффективная проверка данных» - Оригинальная статья Ральфа Меркла (реферат) 1980 года, основа криптографии.
  • «Осваиваем Биткойн» Главы 9 и 10 - Чрезвычайно подробные графические объяснения блоков, транзакций и деревьев Меркла.
  • EIP-4844: Proto-Danksharding - Последнее предложение Ethereum по масштабированию, понимание передовых идей дизайна уровня данных блокчейна.

Теперь, когда вы понимаете физическую структуру реестра, в следующем разделе (1.4) мы углубимся в «Адреса и ключи: криптографическая основа идентичности блокчейна», исследуя, как публичные и приватные ключи лежат в основе каждой безопасной и надежной транзакции в этом децентрализованном мире.

Share on Twitter