prezentatsiya_zashchita_opanasenko

1.

МАГИСТЕРСКАЯ
ДИССЕРТАЦИЯ
Криптографические
алгоритмы в
блокчейн-технологиях
Опанасенко Даниил Олегович
Направление подготовки 10.04.01 «Информационная
безопасность»
Донецкий государственный университет
Научный руководитель: канд. физ.-мат. наук, доц. Худяков И.И.
1/14

2.

Актуальность и проблема исследования
Почему блокчейн важен
Распределённые системы требуют целостности данных, устойчивости к
подмене и согласования состояния без единого доверенного центра.
Роль криптографии
Хеширование связывает блоки, цифровая подпись подтверждает транзакции, а
консенсус защищает общую историю.
Практическая задача
Показать работу ключей, транзакций, блоков, Proof-of-Work и доверия узлов в
программном прототипе.
Ключевой вопрос: как обеспечить доверие в сети, где участники не обязаны доверять
друг другу напрямую?
2/14

3.

Цель, объект, предмет и задачи
Цель
Объект
Предмет
Исследовать криптографические алгоритмы в блокчейнтехнологиях и разработать программный прототип
защищённой сети.
Блокчейн-технологии как средство
обеспечения безопасности информации.
Криптографические алгоритмы,
применяемые в блокчейн-системах.
Основные задачи работы:
1
Изучить хеш-функции, подписи и алгоритмы
консенсуса
2
Рассмотреть угрозы блокчейн-систем и защиту от
подмены
3
Разработать прототип Trust Blockchain PoW
4
Проверить работу сети из трёх узлов и механизм
trust_score
Теория + программная реализация +
экспериментальное тестирование
3/14

4.

Криптографическая основа блокчейна
Хеширование SHA-256
Цифровая подпись
Связь блоков
Одностороннее преобразование данных.
Любое изменение входа приводит к новому
хешу.
Транзакция подписывается закрытым
ключом отправителя и проверяется
открытым ключом.
Поле previous_hash делает цепочку
зависимой от истории и выявляет
подмену.
ЭЦП отвечает за подлинность действия, хеши — за целостность данных, консенсус — за согласование
цепочки.
4/14

5.

Алгоритмы консенсуса и выбранный подход
Proof-of-Work
Proof-of-Stake
Узел подбирает nonce, чтобы хеш блока
соответствовал заданной сложности.
Право подтверждения блока связано с
долей владения/залогом валидатора.
PoA / PBFT
Репутация
Подходы для закрытых сетей с
известными участниками и
голосованием.
Участие узла зависит от истории
поведения и рейтинга доверия.
В прототипе реализован гибрид: упрощённый Proof-of-Work + динамический рейтинг
доверия узлов trust_score.
5/14

6.

Архитектура программного прототипа
node_1
127.0.0.1:8001
node_2
127.0.0.1:8002
node_3
127.0.0.1:8003
Узлы — это серверы сети, а не кошельки
пользователей.
Swagger UI используется как панель тестирования APIметодов разработанного узла.
Что хранит каждый узел
локальную цепочку блоков, pending-транзакции, список peerузлов, правила проверки и рейтинг доверия.
6/14

7.

Кошельки и проверка транзакций
Alice
private_key
Подпись
транзакции
Bob
address
В переводе Alice → Bob получатель указывается адресом.
Публичный ключ Bob не нужен, пока Bob не тратит
средства.
1. Адрес
2. Подпись
public_key отправителя
хешируется и сверяется с sender.
public_key проверяет подпись,
созданную private_key.
3. Баланс
4. Pending
Проверяется достаточность средств и
отсутствие двойной траты.
Корректная транзакция попадает
в пул ожидания.
7/14

8.

Пул ожидания и формирование блока
Tx1
Tx4
Tx2
Tx5
Tx3
Tx6
Кандидат-блок
первые 5
транзакций
pending transactions
Остальные транзакции остаются ждать следующего
раунда.
До майнинга
После блока
транзакция принята узлом, но
ещё не подтверждена цепочкой.
транзакции считаются подтверждёнными,
а баланс пересчитывается.
В демонстрации один раунд майнинга
создаёт один блок; максимум 5 транзакций
в блоке.
8/14

9.

Proof-of-Work: подбор nonce и победитель раунда
Алгоритм
Проверка
Результат
Узел меняет nonce и пересчитывает SHA256, пока hash не начнётся с требуемых
нулей.
Другие узлы не расшифровывают
hash, а пересчитывают его по блоку и
nonce.
В блок записываются validator, nonce,
difficulty, pow_attempts, mining_time,
hash.
9/14

10.

Связанность блоков через previous_hash
Блок 1
hash = A
Блок 2
previous_hash = A
hash = B
Блок 3
previous_hash = B
hash = C
Если изменить старый блок
его hash изменится, а следующий блок будет хранить старый previous_hash —
цепочка станет недействительной.
Proof-of-Work усиливает защиту
На скриншоте в GET /chain видно: hash
одного блока совпадает с previous_hash
следующего.
для скрытия подмены пришлось бы пересчитать nonce для изменённого
блока и всех последующих.
10/14

11.

Рейтинг доверия узлов trust_score
Идея новизны
Узел оценивается не только по факту подбора nonce, но и по корректности
поведения в сети.
Плюс к доверию
Минус к доверию
корректный блок,
правильный hash, валидные
транзакции.
неверный previous_hash,
некорректная подпись, ложный
Proof-of-Work.
Адаптивность
Блокировка
чем ниже trust_score, тем
выше сложность майнинга.
при критическом рейтинге
узел исключается из
майнинга.
В примере node_1 получил снижение рейтинга
после нескольких неуспешных проверок.
11/14

12.

Моделирование атак и реакция системы
Fake signature
Fake block
Double spending
Попытка провести транзакцию без
корректной подписи отправителя
отклоняется.
Блок с неправильным hash или
previous_hash не принимается сетью.
Повторная трата одного баланса
обнаруживается при проверке
транзакций.
Результат: некорректные данные отклоняются, а trust_score узла-нарушителя снижается.
12/14

13.

Результаты демонстрационного эксперимента
Пример блока №2
validator = node_2; nonce = 4671; difficulty = 3; hash начинается с 000.
Пример блока №3
validator = node_1; nonce = 13182; previous_hash совпадает с hash блока №2.
Синхронизация
после /chain/resolve одинаковая цепочка и балансы отображаются на разных узлах.
Подтверждено: блоки создавались разными узлами, хеши соответствовали сложности, а
цепочка оставалась связанной.
13/14

14.

Основные результаты
1
реализована сеть из трёх узлов
2
создание кошельков и адресов
3
цифровая подпись транзакций ECDSA
4
хеширование SHA-256 и связь previous_hash
5
упрощённый Proof-of-Work с nonce
6
динамический рейтинг доверия trust_score
7
моделирование атак и синхронизация цепочки
Цель работы достигнута: показано применение криптографии для
подлинности транзакций, целостности блоков и согласования состояния
между узлами.
14/14