⛓ Как работает блокчейн? Объяснение для гиков на примере работы системы контроля версий VCS
Блокчейн — это не только биткоин. Рассказываем о практическом использовании технологии блокчейн, проблемах при разработке и методах их решения, а также способах достижения append-only, прозрачности и криптографической проверяемости.
Введение
Блокчейн — это комплексное решение проблем информатики в виде единой, общедоступной только для добавления, прозрачной и криптографически проверяемой базы данных, работающей в распределенной и децентрализованной среде.
Блокчейн ассоциируется с технологией, которая ищет проблему для решения. Однако, технологии и компьютерные науки, лежащие в основе блокчейна, на практике применяются в повседневных инженерных задачах. Например, система проверки управления зависимостями.
Возьмем в качестве примера способ, гарантирующий, что в любое время, когда берется код из VCS (системы контроля версий), это будет один и тот же код независимо от времени извлечения.
На рис. 1 показан упрощенный рабочий процесс для системы, предоставляющей способ проверки неизменности извлекаемого кода. Система состоит из базы данных, хранящей хэш (значение) для репозитория в системе контроля версий по некоторому тегу (ключу). Допустим, можно создать клиентский инструмент, извлекающий код из VCS, хеширующий код на диске, запрашивающий значение хеш-функции в базе данных и сравнивающий два хеша. Если ключа нет, то система напрямую обратится к VCS для добавления новой записи и получения хэша.
Преимущество этого подхода в том, что, если хоть один байт кода изменился (с момента первого извлечения), хэш не будет совпадать и сразу станет известно, что кто-то внес изменение в эту версию кода. Это возможно, поскольку разработчик может удалить метку, обновить код и снова применить метку.
Эта система работает для личного использования, так как есть гарантия, что владелец системы не будет ничего ломать в базе данных. Однако, если дать доступ к системе другим пользователям, необходима возможность доказать две вещи:
- Существующие записи в базе данных никогда не обновляются.
- Единственные операции, выполняемые над базой данных — чтение и добавление.
Аудируемая база данных
Один из вариантов решения проблемы — убедиться, что база данных поддается аудиту. Другими словами, чтобы пользователи могли убедиться, что никакие данные не были изменены после добавления. С этим поможет криптография.
На рис. 2 показано изменение, делающее базу данных криптографически проверяемой. Добавляются два новых поля: хэш предыдущей записи и номер записи. Хэш вычисляется для всех данных, представленных в каждой записи, поэтому, если хоть одна запись изменена, хэш будет другим. Поскольку хэш каждой записи основан на хэше предыдущей записи, то записи, по сути, связаны друг с другом. Чем выше в цепочке изменится запись, тем большее количество записей ниже необходимо изменить, чтобы сохранить криптографический контрольный след.
Благодаря этим двум новым полям, аудит базы данных может быть проведен в любое время. Начиная с любой записи создаются хэши и проверяются по всей длине. Это гарантия того, что никогда не было вмешательства в базу данных.
Прозрачность
Проблему аудита решили. Теперь возникла проблема прозрачности. Прозрачность достигается доверием к системе — гарантии того, что размещенная база данных не была изменена автором и не были исправлены все хэши, чтобы база данных оставалась криптографически надежной.
Для этого требуется добавить в клиентский инструмент поддержку, чтобы пользователи могли скачать копию базы данных и сравнить со своей копией базы данных. Это важно, чтобы люди знали, что никаких махинаций не происходит. Причем, вся база не нужна, они могут начать с любой точки, поскольку криптографический контрольный журнал связан цепочкой. Также нужен способ обновлять копию базы данных с течением времени, чтобы обеспечить доверие между сторонами.
Централизованное владение
Проблема прозрачности решена. Рассмотрим средства защиты у пользователей, если они заметят, что владелец изменил базу данных. Для этого необходимо дать другим пользователям возможность размещать базу данных самостоятельно. Никто не должен рисковать тем, что один человек или компания контролирует базу данных. Это решит проблему единственной точки отказа.
Одна из идей — попросить кого-то разместить вторую базу данных и настроить балансировщик нагрузки, такой как Caddy или API-шлюз, такой как KrakenD.
Но, к сожалению, такой подход приведет к тому, что базы данных не будут синхронизироваться.
На рис. 3 показано, что может произойти между каждой базой данных. Поскольку балансировщик нагрузки балансирует запросы между двумя базами данных, разные ключи и некоторые из одних и тех же ключей будут существовать как разные номера записей.
Это не проблема, если хеш-информация для данного ключа одинакова в обеих базах данных. Однако, не исключена вероятность того, что хэш для одного и того же ключа может быть разным в каждой базе данных. Посмотрите на ops@v1.7.5 и заметьте, что присутствует другое значение хеш-функции. Код для этой зависимости был изменен между моментом запроса исходной базы данных и моментом запроса другой базы данных.
Технически оба правильные, но это не поможет пользователю. Необходимо иметь избыточность, при которой любой мог бы обратиться к любой базе данных и получить тот же результат.
Живучесть и репликация
Наличие нескольких версий базы данных нарушает необходимую согласованность. Значение любого ключа всегда должно быть одинаковым, независимо от того, к какой базе данных обращается пользователь. Это сложно из-за того, что требуется дать возможность всем базам данных читать и добавлять записи.
Можно добавить только одну базу данных для добавления новых записей, а остальные использовать только для чтения. Если база данных для чтения содержит недостающий ключ, она может послать запрос базе данных для добавления, где она может выполнить работу. Затем новая запись может быть реплицирована в другие базы данных.
Однако, если база данных добавления выходит из строя, система потеряет жизнеспособность, поскольку такое решение создает централизацию вокруг базы данных приложений и единую точку отказа. Одним из решений может быть выбор новой базы данных добавления, но это решение сопряжено с большими сложностями. Одна из проблем заключается в том, что нет гарантии, что все прочитанные базы данных будут синхронизированы в то время, когда будет происходить выбор базы.
Децентрализованное решение, в котором каждая база данных может выполнять чтение и добавление, позволит системе поддерживать работоспобность даже при выходе из строя любой из баз данных. Для реализации подобной архитектуры понадобится одноранговая (P2P) сеть, в которой можно реализовать P2P-репликацию.
На рис. 5 показана новая архитектура, в которой разные люди и организации могут поддерживать, использовать и делиться базами данных с окружающими. Такое решение предоставляет оперативность и децентрализацию при сохранении единой реплицированной базы данных.
Атомарные дополнения
Теперь требуется гарантировать, что каждая база данных является абсолютно одинаковой при добавлениях в локальных базах данных. Каждое добавление увеличивает номер записи и привязывается к журналу криптографического аудита для этой базы данных. Необходимо реализовать атомарную запись во все базы данных в децентрализованной P2P-сети.
Можно было бы реализовать упрощенную форму протокола консенсуса, который будет координировать, какая база данных будет выполнять следующее добавление к базе данных и синхронизировать это добавление по P2P-сети перед следующим добавлением. Рассмотрим 2 протокола консенсуса для моделирования системы: Proof of Work (PoW) и Proof of Authority (PoA).
Минусы Proof of Work (PoW):
- Базы данных должны конкурировать друг с другом за следующее добавление в базу данных.
- Каждая база данных тратит энергию на борьбу, не зная, кто и когда победит.
- Между каждым новым добавлением в базу данных нет согласованной частоты.
Плюсы Proof of Work (PoW):
- Система остается на 100% децентрализованной.
Минусы Proof of Authority (PoA):
- Требуется централизованная система регистрации, в которой узлы имеют право на добавление.
- Список авторизованных узлов должен быть известен всем другим авторизованным узлам.
- Нужен алгоритм выбора, который каждый авторизованный узел запускает одновременно.
- Детерминированный, чтобы узлы получали один и тот же ответ при каждом запуске по времени.
- Случайный для равномерного распределения выбора.
Плюсы Proof of Authority (PoA):
- Между каждым новым добавлением в базу данных существует согласованная частота.
- Энергетическая расточительность PoW устранена.
Выбор протокола консенсуса сводится к нескольким моментам:
- Нужна ли чистая децентрализация или некоторая централизация допустима?
- Модель PoW довольно проста, но устраивает ли энергетическая неэффективность?
- Модель PoA является энергоэффективной, но устраивает ли дополнительная сложность?
Примечание: При еще большей сложности решением может быть – убрать централизованную систему регистрации в решении PoA и построить вторую P2P-сеть узлов, которые будут заниматься регистрацией, координацией и управлением выбором.
Выберем более простую модель до того, пока усложнение не станет необходимым. При этом расточительность имеет реальные последствия для любой системы как внутри, так и снаружи. Эти различные инженерные компромиссы сложны, поскольку нет очевидного правильного ответа.
Ожидающие записи
Еще одна проблема, существующая независимо от выбранного протокола консенсуса – ожидающие записи. После начала консенсуса требуется некоторое время для его завершения. Пока происходит консенсус, новая запись, сгенерированная клиентом, должна храниться как ожидающая запись. Тогда клиенту должно быть сказано, что невозможно получить ответ, пока эта ожидающая запись не будет официально добавлена в базу данных. Поэтому скорость достижения консенсуса важна.
Более того, клиенты, взаимодействующие с разными базами данных, могут генерировать множество ожидающих записей, пока выполняется консенсус. Эти отложенные записи должны быть помещены в область хранения до начала следующего раунда консенсуса. Решение этой проблемы – добавление пула памяти в архитектуру для хранения этих отложенных записей.
Это еще не все. Ожидающие записи в пуле памяти должны быть разделены по сети P2P, для обеспечения согласованности и надежности системы. При выборе PoW эти ожидающие записи не будут использоваться совместно: ожидающие записи в пуле памяти конкретной базы данных могут никогда не быть добавлены, так как эта база данных, возможно, никогда не выиграет соревнование. При выборе PoA пользователю придется ждать, пока эта база данных будет выбрана алгоритмом выбора.
Благодаря пулу памяти, теперь можно эффективнее добавлять и передавать новые записи. Вместо того чтобы отправлять одну запись зараз по сети P2P, теперь можно отправлять пакет записей на основе того, что хранится в пуле памяти.
Имея в наличии:
- решение для децентрализованной P2P-сети, ожидающее обмена записями;
- протокол консенсуса, обеспечивающий атомарную запись;
- прозрачность и базу данных, содержащую криптографический журнал аудита.
можно построить развернутую систему.
Большая часть техники и стратегии, рассмотренная выше, также используется технологиями блокчейна.
Стимул
Были найдены решения технических проблем, однако остается нетехническая проблема, которую требуется решить: создать стимул для других размещать и публиковать собственные базы данных. Запуск базы данных требует денег, времени и обязательств. Люди не будут делать это по доброте собственного сердца.
Хостинг базы данных может почти ничего не стоить при выборе PoA. При выборе чистой децентрализации и использовании PoW, размещение базы данных может иметь значение в связи с постоянной нагрузкой на процессор.
При выборе PoA, люди, добавляющие базы данных потратив время и немного денег, могут стать злоумышленниками. Для них это может быть забавным развлечением. Возможно имеет смысл рассмотреть замены PoA на Proof Of Stake (PoS) и потребовать, чтобы люди или компании делали ставки прежде, чем станут участниками.
Вывод
В статье рассмотрели технические аспекты технологии блокчейн, которые могут быть использованы для создания единой, доступной для добавления, публичной, прозрачной и криптографически проверяемой базы данных, работающей в распределенной и децентрализованной среде для управления версиями исходного кода. По пути рассмотрели различные проблемы и компромиссы. В конце были рассмотрены стимулы и нюансы, связанные с ними.
Материалы по теме
- ⛓ 23 ресурса для изучения технологий блокчейн: блоги, медиа, сообщества и курсы
- 🐍 Как Python применяется в блокчейн
- ⛓ Не только криптовалюты: реальное применение технологий блокчейна