Из чего действительно состоит блокчейн. Блокчейн часть 5⁠⁠

Блокчейн - это просто база данных, с открымыми данными, открытым кодом и открытым взаимодействием.

Много народа мне уже написало, что эта БД неэффективная и ненужная.

Как инженер я должен ответить вопросами: неэффективная в каких задачах? Ненужная в каких задачах и условиях?

Для меня ответы очевидны, но коли приходят вопросы от вас, значит не всем они очевидны. Давайте тогда рассмотрим устройство подробнее и заодно сравним его с обычными базами данных: Mysql, Postgres, Casandra. На самом деле теория баз данных везде одна и блокчейн практически не использует никаких уникальных подходов или алгоритмов, которые бы не жили в мире баз данных и особенно распределённых баз данных. Блокчейн - это скорее про удачное сочетание существующего, чем про совершенно новое.

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

LevelDB, RocksDB, BadgerDB, LDBX и многие другие. Это чтобы у нас на диске были все данные по номерам счетов и их состоянию. Тут никакой экзотики, эти базы данных используют в во встраиваемом оборудовании, и в обычных клиент-серверных приложениях.

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

Значит нам надо уметь соединяться с другими базами с копиями блокчейна. Надо уметь с ними общаться, чтобы мы были друг другу полезны. И надо находить такие базы в сети.

Отлично. Это 3 задачи.

Как находить другие базы с блокчейном? Для этого делают то, что называется discovery. По сути всё очень просто: предоставляется начальный список работающих серверов этого блокчейна, вот прямо в коде забит может быть. Список этот поддерживается несколькими крупными фондами или организациями, список можно дополнять своими адресами по желанию. И тут нет ничего необычного для знакомых с базами данных, собирая кластер MySql, MongoDB, мы ведь тоже даём некий начальный список, куда кому соединяться, чтобы начать работать или получить список остальных серверов. Вот мы и соединяемся и шлём запрос "а я блокчейн, допустим, Эфириум, дай мне ещё адресов таких же". И тебе дают. Так ты пополняешь свою собственную адресную книжку адресов серверов блокчейна для будущих соединений. С них мы и будем брать блоки и транзакции, им и будем слать блоки и транзакции.

Надо уметь общаться с соседними серверами. Тут всё просто. Есть протокол из списка сообщений, как запросить блок, как отдать блок, тоже про транзакцию, тоже про ещё несколько штук, которые полезны для более лёгких и быстрых серверов. В Ethereum это протокол `Eth/XX`, текущая версия ETH/66 - https://eips.ethereum.org/EIPS/eip-2481. Он совсем небольшой, буквально 10 видов сетевых сообщений. Опять-таки ничего необычного - любая база данных имеет протокол общения между серверов и этот протокол стараются держать небольшим и понятным.

Сначала я думал, что это будет лишним, но давай весь протокол общения посмотрим. Вот он, 5 пар вида СообщениеЗапроса -> СообщениеОтвета. Какие-то сейчас непонятны, но всё же:

GetBlockHeaders -> BlockHeaders

GetBlockBodies -> BlockBodies

GetPooledTransactions -> PooledTransactions

GetBlockBodies-> BlockBodies

GetNodeData -> NodeData

GetReceipts -> Receipts

Вот и ответ на 3х вопрос. Как нам брать новые блоки и транзакции: GetBlockBodies(запросить блоки транзакций) и GetPooledTransactions(запросить отдельные транзакции).

Хорошо, что нам ещё нужно?

Нам нужно уметь проверять транзакции.

Как мы это делаем? По сути все проверки делятся на 2 вида - базовые и непосредственно исполнение транзакции. Базовые это проверки, а нет ли в транзакции банальных ошибок. Подпись неверная, время в далёком будущем, формат неверный.

Если транзакция прошла базовые проверки, то мы помещяем её в отдельную небольшую базу данных по имени TransactionPool или MemPool. Чтоб не потерялась и в случае перезагрузки.

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

Этот шаг необходим, чтобы транзакция не застряла.

И это не есть ничего необычного. Все базы данных делают подобное. Кому интересно, это протокол gossip, протокол, пораждающий "эпидемию" распространения сообщения в сети. Разработан в далёком 1987 году и многократно проверен и доказан, что сообщения не теряются и рано или поздно доходят до всех серверов в сети.

Я упомянул, что мы проверяем время в транзакции.

Время. Это тоже часть системы и нам без неё никуда. На секунду задумайтесь, что такое время, если у нас с сотню тысяч серверов, не поднконтрольных нам. У каждого может быть своё время. И вот нам присылают блок и в нём есть метка времени. Как нам понять, не слишком ли он старый? Да, у него есть ещё и порядковый номер, но нам надо проверять и номер и время.

Время в распределённой сети, строго говоря, не определено. Можно лишь определить отношение порядка, закон, как нам выстраивать события по порядку. Но это добавляет сложности и сильно так добавляет.

В Эфириуме в итоге решено это так, что мы считаем время тем, же, если оно укладывается в интервал нашего времени плюс-минус 10 секунд (или 6, не проверю сейчас код).

Осталось транзакцию исполнить. Это и есть основная её проверка.

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

Есть особенности: иногда мы исполняем не просто транзакцию, а транзакцию с кодом. Это давайте отдельно статьёй про Эфириум.

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

Что у нас осталось?

Осталось согласовать, какие транзакции и в каком порядке мы должны применять к базе данных.

Этим и занимаются майнеры или валидаторы или sealers (не придумал, как перевести). С вашего позволения, назову это всё майнингом.

Майнинг.

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

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

Можно начать расписывать, как именно происходит соревнование, но я это оставлю до статьи про Эфириум. Туда же отправляется вопрос, а что происходит, если в сети несколько победителей.

Вот и все части блокчейна. Они направлени только и исключительно на одно. На то, чтобы мы все считали истиной один и тот же список финансовых счетов и их состояний.

Прошлые статьи:

Нужен ли рассказ, как работают криптовалюты с точки зрения разработчика и кода?

Chain без магии. Blockchain. Часть 1

Блокчейн - это просто медленная база данных для особых задач. Давайте ее построим. Blockchain. Часть 2

Блокчейн применения. Или зачем он нужен такой странненький? Blockchain. Часть 3