Маленькая книга о блокчейне #

Вводная #

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

Итак…

Блокчейн #

Термин пошел от английского “block chain”, что переводится как “цепочка блоков”. Каждый новый блок содержит хэш предыдущего блока, образуя односвязный список, в котором хэш каждого блока записан в следующем блоке.

Хэш блока зависит от всех предыдущих блоков. Таким образом, хэш последнего блока отражает состояние всей базы. А цепочка хэшей от последнего блока к первому является доказательством её неизменности. При добавлении нового блока он “увязывается” с последним блоком и его хэш становится новым состоянием базы.

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

Вот, собственно, и всё.

База данных #

Мы уже знаем, что блокчейн это всего лишь способ защитить базу данных от вмешательства. Какой же должна быть сама база данных? На самом деле, она может быть любой - SQL, BigTable, Key-Value, файловой системой. Но использование блокчейна накладывает свои ограничения.

База данных, защищенная блокчейном, из четырех свойств CRUD (“Create, Read, Update, Delete”) допускает только первые два. Ни менять, ни удалять данные из такой базы нельзя - потому, что она тут же потеряет криптографическую целостность. Блокчейн позволяет только читать и создавать новые блоки.

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

Ключевое слово здесь - “почти”. Есть способ примирить “полноценную” базу данных с блокчейном и способ этот называется “журналом транзакций”.

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

Для каждой сущности рассчитаем хэш, а затем литерально упорядочим (отсортируем по алфавиту) полученный список. Для каждой пары хэшей рассчитаем хэш литеральной суммы (конкатенации) этих хэшей. Затем над полученным списком сделаем то же самое. И так до тех пор, пока не построим дерево хэшей, на вершине которого будет одно-единственное значение. Этот механизм называется деревом Меркла и на вершине его будет хэш, который отражает состояние базы данных.

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

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

В принципе, такую же схему можно реализовать и для реляционной базы, и для любой другой - в случае необходимости. Журнал транзакций будет фиксировать изменения, дерево Меркла - доказывать достоверность самой базы данных. Неплохо, правда?

Децентрализация данных #

Зачем вообще заморачиваться со всеми этими механизмами доказательства подлинности? Затем, что так можно построить распределенную базу данных, которой можно доверять. Даже если самим узлам сети, в которой хранится эта база, мы не доверяем.

Децентрализованные базы данных бывают реплициируемые и распределенные. Реплицируемые базы данных хранятся у каждого пользователя одинаково и полностью, а распределенные - по разному и частично. Плюс первого подхода в полном контроле над базой данных, а минус - в высоких требованиях к объемам хранения. Плюсы и минусы второго подхода зеркальны - объем всей базы может многократно превышать возможности любого отдельно взятого пользователя, но ценой недостаточного контроля и, следовательно, снижения доверия к её достоверности.

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

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

Распределенная сеть #

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

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

Самой простой архитектурой является полносвязный граф, в котором каждому идентификатору соответствует реальный сетевой адрес и существует возможность связи всех со всеми. Но в реальной сетевой инфраструктуре возможность связи всех со всеми может и не быть. Кроме того, из-за необходимости оповещения всех участников с ростом сети трафик будет расти пропорционально числу участников. Рано или поздно наступит предел эффективности, за которым начнется деградация сети, вплоть до её полной остановки.

Более сложная модель представляет собой направленный циклический граф. Идентификаторы упорядочиваются в единый список, который закольцовывается так, чтобы у каждого узла были “соседи” слева и справа. Получая сообщение от соседей слева и отправляя его вправо, узлы доставляют его по “эстафете”. Эта схема не зависит от размера сети, потому что узлы взаимодействуют со сравнительно небольшим фиксированным числом соседей. Эту схему можно улучшить и дополнить, но суть в том, что каждый узел будет взаимодействовать лишь со своей подсетью, которые, частично пересекаясь, реализуют связный граф ничем не ограниченного размера.

Но и это не дает решения для ситуаций, в которых узлы могут соединяться с другими в одностороннем порядке. Участники из частных сетей, скрытых за маршрутизаторами с сетевой трансляцией адресов (NAT), могут инициировать подключение, но не могут их принимать. Для них необходимо реализовывать модель, при которой они устанавливают соединение, а сообщения получают в ответ на запрос. “Проблема обхода NAT” может иметь решение в виде отдельных “маяков”-маршрутизаторов или других узлов, реализующих эти функции. Схема с маршрутизаторами аналогична схеме “звезда” сетевой архитектуры.

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

Но за все надо платить. Математический аппарат mesh-сетей (от англ. mesh - “ячейка”) в разы сложнее и от его описания здесь я, пожалуй, воздержусь. Интересующихся отошлю к “задаче коммивояжера”, а затем - если и это их не отпугнет - к теории игр. Там есть все ответы - для того, кто сумеет их добыть.

Проблема ветвления #

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

Особенно актуальна эта проблема в децентрализованной системе, где разные узлы независимо друг от друга могут вносить изменения в базу данных, порождая форки (от англ. fork - “развилка”). Бороться с этим можно двумя способами - избеганием ситуации одновременной записи и устранением последствий.

Майнинг #

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

В каждый новый блок добавляется случайное число. Случайное-то оно случайное, но хэш полученного в результате блока должен соответствовать условиям. К примеру, начинаться с 10 нулей. И вот узлы, желающие записать новый блок, перебирают эти числа до тех пор, пока хэш блока не станет отвечать заданным условиям сложности. И “фермы” из компьютеров, видеокарт или специально сконструированных устройств поглощают киловатты и производят тепло. Ну, и нужные хэши, разумеется.

Зачем все это? А очень просто. Из всего множества участников по теории вероятности хэш находится раз в 10 минут кем-то одним. Он и записывает блок. Это самый простой способ защиты от ветвления.

И самый неэффективный, потому что, несмотря на сложность задачи, “форки” случаются. Тогда обнаружившие “вилку” удаляют блоки из более короткой ветки и последовательно переносят её в конец более длинной.

А чтобы участникам сети было интересно заниматься всем этим, за потраченные ресурсы они получают криптомонетки “из ниоткуда”. Это и есть майнинг (от англ. “mining” - работа на руднике).

PoW, PoS, DPoS… #

Вычисление хэшей - это только один из способов выбрать одного из многих. Это Proof-of-Work, что означает “доказательство проделанной работы”. Вычисляя нужный хэш, участники выполняют работу, а найденный хэш и есть это самое доказательство. Доказательство впустую потраченной электроэнергии.

Когда об этом говорили “зеленые”, это мало кого волновало. Но, когда новые деньги стали угрожать старым, об экологии вспомнили правительства. Впрочем, бесполезность майнинга к тому времени не понимал только тот, кто получал за это деньги. Пришло время что-то менять…

И появился Proof-of-Stake, “доказательство владения”. Тут все просто, кто богаче - тот и прав. На самом деле, чуть-чуть сложнее, но не принципиально - создание блоков (и получение вознаграждения за них!) в руках тех, у кого доля владения выше.

Потом появился DPoS (делегированный PoS с демократией и голосованием), PoI (“доказательство важности” на основе каких-то метрик вроде активности операций и времени uptime) и прочая, и прочая, и прочая…

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

А если не доказывать? #

А вот здесь остановимся и вспомним, почему нам так критично, чтобы запись производилась кем-то одним. Да, чтобы цепочка не разделилась в дерево. Но почему?

Если у цепочки есть два финальных блока, то база данных одновременно находится в двух состояниях. А если больше - в суперпозиции всех состояний. База становится неопределенной. Вся база, целиком. А нужна ли нам монолитная целостность базы? Для того, чтобы проверить достоверность элемента, не нужна вся база - нужны лишь те её части, которые с ним связаны.

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

Это блокчейн без блокчейна. Точнее, реестр на ациклическом направленном графе.

Криптовалюта #

Мы говорим “криптовалюта” - подразумеваем “блокчейн”, мы говорим “блокчейн”… но нет, обратное неверно. Что же такое криптовалюта?

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

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

Эмиссия #

Если мы считаем бумажные деньги государственными долговыми расписками, значит вся сумма денежных знаков это совокупный долг государства своим гражданам. И если на их счетах разные числа со знаком плюс, то на условном “государственном счете” сумма их всех со знаком минус. Тогда все сходится.

Бухгалтеры называют это равновесие “балансом”, у них тоже есть активные (строго-отрицательные) и пассивные (строго-положительные) счета. У них есть также активно-пассивные счета, но “если рассудок и жизнь дороги вам, держитесь подальше от торфяных болот” бухгалтерского учета, потому что там есть даже “баланс по внебалансовым счетам”, существование которого способен вынести не всякий разум.

Смысл в следующем. Благодаря тому, что счета эмитенты могут быть отрицательными, они переводят деньги, которых у них нет и тем самым “печатают” их. Теоретически они могут делать это в любых количествах. На практике же эмитент является частью системы, которая должна регулировать денежную массу. Как это сделать - каждый проект решает сам.

Инфляция #

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

Инфляция является побочным эффектом любой эмиссии. Его по возможности надо избегать.

Дефляция #

Если какую-либо сумму перевести на счет эмитента, то эти деньги будут “сожжены”. Количество денежной массы уменьшится, стоимость денежной единицы вырастет и все участники системы станут чуточку богаче. Кроме того филантропа, разумеется, кто вывел свои деньги из обращения.

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

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

Главное, как и во всем, равновесие и чувство меры.

Не только деньги #

Когда мы говорили о блокчейне, то упоминали произвольные базы данных, а не только записи “счет-счет-сумма”. Так вот, мы можем хранить любую информацию в распределенной базе данных. Это открывает большие возможности. Общедоступная база данных, которую нельзя уничтожить и фальсифицировать, везде найдет применение.

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

Умные контракты #

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

В криптовалютах смарт-контракт - разновидность участника, который не живой человек, а автомат, чье поведение определено кодом. Когда выполняется операция перевода денег этому участнику, код выполняется. Он может делать что угодно - переводить полученную сумму другим участника по частям, копить полученные деньги до часа X и потом выбрать кого-то одного и перечислить все деньги ему. Последнее, кстати, является классической реализацией всяческих “рулеток”, “лотерей” и “тотализаторов”. Может и просто сохранять в базу информацию о том, что какой-то участник оплатил услугу, а потом другой подключенный участник сможет эту информацию получить и предоставить услугу.

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

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

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

Так мы внутри распределенной базы сможем создать распределенную же виртуальную машину. Такую же достоверную (то есть проверяемую), как и все остальное.

Заключение #

Вот, собственно, и все. Громадное количество нововведений - всего лишь более эффективные реализации описанных идей. Если вам говорят о чем-то “революционном”, просто знайте - вас хотят обмануть. Кстати, пирамиды по типу МММ в крипте уже появились.

Спасибо за внимание.