Цепочки хешей и связывание блоков

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

Каждый блок содержит: (1) полезную нагрузку данных (транзакции), (2) хеш предыдущего блока (указатель на предыдущий блок), (3) временную метку, (4) nonce (для PoW), (5) корень Меркла транзакций. У первого блока (генезисного) значение previous_hash = "0"*64.

import hashlib, json class Block: def __init__(self, data, prev_hash): self.data = data self.prev_hash = prev_hash self.hash = hashlib.sha256( json.dumps({'data':data,'prev':prev_hash}).encode() ).hexdigest()

Если злоумышленник изменит данные блока 3, хеш блока 3 изменится. Блок 4 ссылается на старый хеш блока 3 — цепочка разрывается на блоке 4. Злоумышленнику придётся заново вычислить хеши блоков 3, 4, 5 и так далее вплоть до конца цепочки. При использовании PoW это вычислительно невыполнимо.

Хеш-цепочки сами по себе позволяют обнаруживать изменения, но не обеспечивают неизменяемость. Без дополнительных механизмов (PoW, цифровых подписей и распределения) злоумышленник, контролирующий цепочку, может переписать её. Именно распределённый консенсус на практике делает блокчейн устойчивым к изменениям.

Правило самой длинной цепочки Биткоина: канонической считается действительная цепочка с наибольшим совокупным объёмом доказательства выполнения работы. Если злоумышленник создаёт ответвление цепочки, честные майнеры расширяют честную цепочку быстрее (допущение о 51%). Ответвление злоумышленника оказывается короче и отбрасывается.

Клиенты SPV Биткоина (простая проверка платежей) загружают только 80-байтовые заголовки блоков, содержащие предыдущий хеш, корень Меркла, nonce, временную метку и bits. Полные узлы хранят все транзакции. Клиенты SPV проверяют транзакцию с помощью доказательства Меркла относительно корня Меркла в заголовке.

Генезисный блок Биткоина (блок 0, 3 января 2009 года) имеет значение prev_hash = 0x000...0. Сатоси встроил в транзакцию coinbase заголовок «The Times, 03.01.2009: канцлер на грани второго спасения банков» как доказательство времени создания.

Хеш-цепочки появились раньше блокчейна. Применение: списки отзыва сертификатов (связанные хешами), целостность журналов (хеш предыдущей записи журнала), цепочка доверия DNSSEC. Этот принцип обобщается на любую структуру, в которую можно только добавлять записи и где каждая запись фиксирует все предыдущие записи.

Чтобы ускорить первоначальную синхронизацию, Bitcoin Core жёстко задаёт контрольные точки: хеши блоков, заведомо признанных действительными, на определённых высотах. Клиент, начинающий синхронизацию, может пропустить проверку PoW для блоков до контрольной точки, доверившись заданному в коде хешу. Компромисс: уменьшается степень минимизации доверия.

Git использует тот же принцип: каждый коммит идентифицируется значением SHA-1/SHA-256, вычисленным по его содержимому и хешу родительского коммита. Переход к определённому хешу коммита восстанавливает ровно это состояние. Вся история Git представляет собой дерево объектов, связанных хешами.

Почему после изменения одного блока злоумышленник должен заново вычислить хеши всех последующих блоков?

Хеш-цепочки связывают блоки с помощью криптографических указателей. Изменение распространяется на все последующие блоки. В сочетании с PoW и распределённым консенсусом это делает блокчейн практически неизменяемым. Далее: деревья Меркла для эффективной проверки целостности транзакций.