---
# System prepended metadata

title: Блокчейн. Часть 1
tags: [stepik-blockchain-kolotov]

---

---
tags: stepik-blockchain-kolotov
title: Блокчейн. Часть 1
---
# Недостатки централизованных систем (1001)
На данный момент блокчейн лучше всего подходит для криптовалют.

- Имеется возможность подменить данные
    - **Пример:** Приходит человек в банк, а на его счету 0 копеек, логи чистые, и никто ничего не сможет доказать
- В случае некорректных его действий падает фактор доверия
    - **Пример:** Блокировка всего и всех счетов из-за долга в 1 копейку на длительный период

## Возможное решение проблемы
Хранение информации обо всех транзакциях у всех участников системы
- Решаемые проблемы
    - Нелегитимные блокировки счетов
- Возникающие проблемы:
    - Проблема консенсуса при синхронизации истории
    - Массовая подмена данных

### Возможные модификации
1. Хранение в транзакции ссылок на предыдущую транзакцию
    - Позволяет быстро перейти из текущей транзакции в предыдущие
    - Создает возможность удаления транзакции подменой ссылки на предыдущую транзакцию
2. Подписывать каждую транзакцию цифровой подписью
    - Обеспечивает неизменность транзакции, т.к. при подмене ссылки на предыдущую транзакцию изменится хэш и цифровая подпись станет нелегитимной и потребуется переподписание
    - Не решает проблему подмены данных при массовом сговоре

## Предложение Сатоши Накомото
Тезисы:
- Вместо использования ссылок на прошлые блоки использовать хэши этих блоков
    - Для подмены или удаления транзакции придется изменить все последующие транзакции и прийти к консенсусу
- Для каждой транзакции должно быть подобрано такое число $nonce$ (соль), чтобы хэш транзакции, к которой приклеили этот $nonce$, удовлетворял определенному условию (например, $nonce \leqslant D$, где $D$ -- Difficulty *(сложность)*) -- так называемый *Proof of Work*
    - Для изменения цепи придется пересчитывать каждую транзакцию и перебирать $nonce$ отдельно для каждой транзакции

# Отличия Биткоина от Эфириума
- Биткоин оперирует хэшами транзакций
    - Изменение состояния баланса на адресах пользователей описывается транзакциями
        - **Например**: Пользователю A пришло 50 шекелей в транзакции 01. Он хочет перевести пользователю B 10 шекелей, и потому создает 2 транзакции: перевод 10 шекелей пользователю B и перевод 40 шекелей себе (пользователю A)
        - Возмонжо отследить хождение конкретных монет. **Например:** кто-то выделил грант в 50 шекелей, и хочет убедиться, что расход был целевым. С помощью такой избыточности информации он может проследить полное хождение этих 50 шекелей по кошелькам.
    - Транзакции, монеты которых не были потрачены, хранятся в Unspent Transaction Output *(UTXO-лист)*
- Ethereum оперирует конкретными балансами
    - Каждая транзакция имеет данные об отправителе, получателе и сумме
        - Невозможно отследить хождение конкретных монет
    - Проверка доступности монет проходит проверкой всех предыдущих транзакций

# Блок
## Основная информация
- Является собранием некоторого количества транзакций (лимитировано размером блока)
    - Размер транзакции зависит от ее типа. **Например:** Из 1 транзакции создается несколько транзакций.
- Difficulty задается и Nonce просчитывается для блока, а не для конкретной транзакции
    - При вычислении хэша вычисляется хеш только заголовка
- Блоки связаны друг с другом хешами (создается цепочка блоков -- Block-Chain)
    - В BTC -- чистый SHA3
    - В ETH -- keccak256

## Merkle Root и Merkle Tree
### Merkle Root
Поле в заголовке блока, которое содержит хэш всех транзакций, входящих в блок

### Merkle Tree
- Древовидная структура, в каждой вершине которой хранится хэш от суммы хэшей детей. 
- Конкатенация и хэширование производится на каждом уровне из одной стороны в другую. Если блоку не досталось пары, попытка задействовать его будет предпринята уровнем выше. В худшем случае оставшийся блок будет объединен с хэшем, группирующим остальные вершины.
- Значение, хранящееся в корне дерева, и называется *Merkle Root*

### Предназначения
1. Прохэшировать все транзакции в блоке (найти *Merkle Root*)
2. Нахождение блока, в котором находятся транзакция

### Little и Big Endian
- **Big Endian** -- байты записываются в порядке убывания номера разряда
    - $10 = 00 00 00 0A_{16}$
    - $258 = 00 00 02 00_{16}$
- **Little Endian** -- байты числа записываются в порядке возрастания номера разряда
    - $10 = 0A 00 00 00_{16}$
    - $258 = 00 02 00 00_{16}$

# Адрес
1. При регистрации вам присвается рандомный *Secret Key* $K$ *(размерность - 256 бит)* -- число в интервале $[1; 2^{256} -1]$, говорящее о том, что вы являетесь владельцем счета
2. С помощью произведения на Eliptic Curve точки $G$ (определенной для всей сети) на приватный ключ $K$ и получаем точку $P$ *(размерность - 256 бит)*, являющаяся *Public Key*.
3. От публичного ключа берется хэш, а от него последние 20 байт. Это -- адрес в блокчейн-сети
    - В Bitcoin конечный результат кодируется в Base58, тем самым возможно подобрать такое $K$, чтобы конечный адрес был похож на какое-либо слово

# Цифровая подпись
Имеется 2 функции:
- `sign(msg, K) -> S` *($msg$ -- сообщение (в данном случае о  транзакции), $K$ -- секретный ключ, $S$ -- подпись)* -- фукнция, возвращающая цифровую подпись сообщения $msg$
- `verify(msg, P, S) -> bool` *($msg$ -- сообщение, $P$ -- публичный ключ, $S$ -- подпись)* -- функция, проверяющая валидность цифровой подписи

Транзакция представляет из себя сообщение, в котором говорится, напримиер, "перевожу 20 шекелей клиенту B", подписанное подписью клиента A.

# Майнинг, и для чего он нужен. Консенсус
## Сокращения
- **Транзакция** -- *(TX)*
- **Блок** -- *(BLOCK)*
- **История блока** -- *(HISTORY)* 

Алгоритмы консенсуса нужны для определения правильности TX, BLOCK и HISTORY для всех узлов

## Действия каждого узла для достижения консенсуса при формировании блоков
1. Проверка TX на валидность
    - Все поля заполнены верно
2. Включение TX в BLOCK
    - Все TX проверяются на возможность этой TX *(напр., проверка на доступность средств, )*
3. Проверка BLOCK на валидность
    - Отсутствие транзакций, уже включенных в другой блок
4. Каждый узел пытается подобрать nonce для своего блока (в каждом из  которых свой список транзакций). В совокупности параметров (производительность, множество транзакций в блоке) достигается псевдослучайность выбора узла, выпускающего блок
5. Блок распространяется по остальными узлам, они проверяют блок и начитают подбирать следующий

## Репутация сети
Основная цель **майнинга**, генерации блоков за вознограждение -- экономическая мотивация майнеров генерировать блоки и обеспечивая транзакциим

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

В случае атаки 51%, попытокк махинировать с транзакциями остальные участники сети видят, что он мухлюет, они могут покинуть сеть и, при сбыте монет, обвалить курс и обесценив усилия махинатора

## Ограниченность ресурсов Bitcoin
В начале работы сети BTC вознограждение за майнинг было 50 BTC/block.
В 2012 -- 25 BTC/block;
В 2016 -- 12,5 BTC/block;
В 2020 -- 6,25 BTC/block;
В итоге каждые 4 года вознограждение за майнинг уменьшается в 2 раза и к 21хх году награждение дойдет до 0.

# Теорема CAP в теории баз данных
**Consistancy -- Availiability -- Perfomance**
Оба 3 составляющие совместить невозможно, только 2 из них

## Методы достижения
### Доступность
- Регулируется частота выпуска блока (BTC -- раз в 15 минут, в ETH -- 20 секунд)
	- Страдает Perfomance, т.к. скорость транзакций в среднем 6-7 в секунду (BTC)

# Ветвление и кластеризация
Из-за несвязности графа сети может произойти ситуация, в которой две удаленные ноды выпускают блок n, и при его распространении нужно решить, какой правилен. Это явление называется **fork**, или *ветвление*.

## Консенсус в Bitcon
Для решения данной проблемы принимается решение отложить вынесение вердикта, и по итогу часть сети начинает работать на одной ветви, другая -- на второй.

Когда наступает ситуация, что одна из нод знает, что в одной ветви - 2 блока, в другой 1, то она принимает за основную ветвь более длинную, и таким образом распространяется ветвь, в которой больше блоков.

**Правило:** мы продолжаем более длинную цепочку, а кроткую -- отбрасываем.

## Консенсус в Ethereum
**Правило**: *GHOST* -- обнаружение наиболее тяжелых цепочек.

До принятия консенсуса каждый блок знает о своем отце *(блок, от которого он порожден)* и дядях *(блоки, которые имеют номер n-1)*.

**Тяжелая цепочка** -- цепочка, у которой наибольшее число *uncle*-блоков. За каждый *Uncle*-блок, который был отброшен, майнеры получают часть награды в качестве экономической мотивации из-за большой частоты

## Новомодоные и сырые методы достижения консенсуса
1. Offchain-транзакции (*Lightning Network AKA Raiden Network*)
	- Контролируются *Payment-channel*
	- Применяется при наличии доверительных отношений
	- Первая часть полной транзакции -- внесение депозита в одной транзакции
	- С течением времени человек, который внес депозит, передает уведомления об оказании услуг
		- При прекращении прихождения уведомлений прекращается оказание услуг
	- Депозит возвращается за вычетом уведомленного

2. Sharding
    - Устанавливается какое-то условие, по которому пользователи сети делятся, и в соответтсвии с этим делением пользователи обслуживаются определенными шардами (кластерами)

3. Plasma
    - Имеется несколько блокчейнов для разных нужд, и они взаимодействуют друг с другом

## Альтернативные способы принятия решений о формирвоании истории блоков

- **Proof of Stake**
    - Решение о выпуске могли принимать только системы, имеющие некоторый баланс
    - Это экономически мотивирует принимать правильные решения, т.к. в обратом случае обесценивается имеющийся у него баланс
    - **Невозможен при пустом блокечейне**, обязательно один блок должен быть выпущен и выплачена за него награда (если блокчейн не предусматривает другого)
    - PoS экономи ресурсы (электроэнергию, компьютерные часы)
- **Proof of Authority** *(доказательство правды)*
    - Используется в блокчейнах с ограниченным количеством участников
    - Заранее определены узлы, имеющие право майнить
    - Происходит монополизация управления блокчейном у определенных узлов

# Основные тезисы
1. Блокчейн -- база данных
    - Простейшая единица записи -- транзакция
    - Между транзакциями имеется криптографически защищенная числом *nonce* связь на основе хэшей с определенными свойствами
2. Криптография на математике элептических кривых
    - Используется пара ключей -- private и public
        - Публичный ключ формирует адрес в блокчейн-сети
        - Публичный ключ -- производная от приватного (*public* = *точка на элептической кривой* \* *private key*)
3. Базовые примитивы
    - Блок -- группа транзакций
    - **Merkle Tree** позволяет в заголовке блока хранить хэш от транзакций
    - Хэш блока организует связь между блоками
        - Хэш блока должен быть меньше, чем число *difficulty*
4. Скорость распространения информации
    - Уменьшение количества транзакций в блоке приводит к дестабилизации блокчейна
    - Майнер строит и валидирует цепочку блоков
    - Майнер за качественную работу получает соответсвующее вознаграждение
5. Консенсус - путь к согласию об установке единой истории состояния блокчейна
    - BTC: Определение самой длинной цепочки
    - ETH: Определение самой тяжелой цепочки алгоритмом GHOST
    - Алтернативные методы
        - Proof of Stake -- право выпускать блок в соответствии с имеющейся долей в сети
        - Proof of Authority -- моноползиация права на выпуск блоков определенными узлами