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

В своей основе все современные криптовалюты — это одноранговые сети (peer-to-peer, P2P), в которых каждый узел является независимой единицей, способной выполнять все множество операций по созданию и верификации транзакций. Потеря любого числа узлов в сети не влияет на ее работоспособность. На данный момент все криптовалюты хранят и передают транзакции, группируя их в блоки ограниченного размера. Сначала узел выбирает некоторое число транзакций, не больше максимального числа, единого для всей сети. Обычно транзакции назначаются исходя из размера комиссии за их исполнение, но возможны и другие варианты. Затем транзакции записываются в блок, который распространяется по всем узлам сети. Таким образом достигается синхронизация состояния узлов по модели eventually consistent («согласованность в конечном счете»), гарантирующей, что, при отсутствии изменений, через какой-то промежуток времени после последнего обновления данные на всех узлах будут синхронизированы. Транзакции, включенные в блок, называются подтвержденными.

Право генерации очередного нового блока определяется моделью консенсуса (consensus model), которую часто называют алгоритмом консенсуса, хотя это не алгоритм в обычном смысле, а скорее математическая модель простого социума — формальный набор законов и правил работы в рамках блокчейн-платформы. Помимо определения очередности генерации следующего блока, модель консенсуса определяет основные критерии работы сети:

  • Размер вознаграждения за генерацию блоков, который мотивирует участников добавлять новые узлы в сеть и в конечном итоге позволяет сети функционировать в децентрализованном режиме, по сути — жить.
  • Частоту генерации блоков, помогающую минимизировать ситуации, когда далеко отстоящие друг от друга узлы генерируют каждый по своему блоку. Конкретной позиции (высоте) в цепочке блоков (отсюда и название технологии — blockchain) может соответствовать только один блок, и при появлении двух блоков, соответствующих одной высоте, возникает конфликт, который обычно решается путем выбора в пользу какого-то одного блока, а транзакции из остальных снова помещаются в список неподтвержденных. Но если частота таких конфликтов превысит определенный порог, то сеть не сможет нормально функционировать.
  • Признак корректности пришедшего с другого узла блока. Обычно это проверка цифровой подписи по той же схеме, что и для транзакций.

На данный момент используются две модели консенсуса: Proof-of-Work (PoW) и Proof-Of-Stake (PoSt).

В модели PoW право генерации блока получает узел, первым справившийся с математической задачей, которая может быть решена только путем перебора всех вариантов. Обычно задача достаточно проста, чтобы математическое ожидание времени выполнения процесса ее решения («майнинга») на стандартном оборудовании было в пределах несколько минут. Чтобы самый быстрый узел сети не имел постоянного преимущества, в число входящих параметров задачи включается и уникальный для каждого узла параметр, например публичный ключ. Таким образом, налицо лотерея, в которой может выиграть любой узел, хотя очевидно, что наличие большой вычислительной мощности является преимуществом. Основной недостаток модели Proof-of-Work — бессмысленный по своей сути расход вычислительных мощностей.

Модель PoSt позволяет избежать этого недостатка PoW, и хотя «лотерея» также имеет место, шансы выиграть в нее пропорциональны числу денежных единиц криптовалюты на счету майнера. Такой подход мотивирует участников сети покупать значительные объемы криптовалюты, что аналогично выпуску акций компании и торговле ими. На первый взгляд, такой подход представляется оптимальным, и пока основным недостатком модели Proof-Of-Stake можно считать лишь ее новизну — модель должна пройти проверку временем (и атаками хакеров).

Процесс разработки ПО для криптовалют напоминает процесс создания коробочных продуктов — количество установок обычно очень велико, а основная масса пользователей обладает минимальными навыками администрирования. Поэтому ПО должно быть максимально простым и достаточно надежным, иначе все информационные каналы службы поддержки будут забиты «шумом» и может быть пропущено что-то важное, ведь любая неточность может открыть ворота для атаки, краж или компрометации сети и, как следствие, привести к падению курса криптовалюты. Иначе говоря, типичная для коробочного продукта тактика выпуска релизов как можно раньше, причем иногда в ущерб качеству, для разработки платформ блокчейна не подходит — баланс должен быть смещен в сторону надежности и безопасности. Поэтому даже на этапе бета-тестирования важно, чтобы качество платформы блокчейна было достаточно высоким для того, чтобы у всех участников разработки была возможность сфокусироваться на главных задачах. По этой же причине требуется тщательно спроектировать все элементы системы (модель консенсуса, протокол взаимодействия узлов и т. д.) и лишь затем приступать к разработке. На этапе проектирования важно также проверить и теоретически обосновать все аспекты, связанные с математикой. Серьезная переработка математических моделей и протоколов «по ходу дела» для платформ блокчейна очень затруднительна — например, замена алгоритма консенсуса означает появление новой криптовалюты, а не изменение старой. В этой связи жизнеспособна будет лишь та блокчейн-платформа, разработчики которой сначала тщательно «прицелились» и только потом «выстрелили». Это не исключает применения agile-подхода, но все ключевые аспекты должны быть спроектированы еще до эксплуатации платформы.

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

Не секрет, что максимально возможное число транзакций в единицу времени в блокчейне ограничено самим протоколом: частота генерации блоков не может быть больше, чем заранее определенная достаточно большая величина, а число транзакций в одном блоке тоже ограничено. Попытки повысить частоту генерации блоков поражают разнообразием и сложностью вариантов. Хороший пример — подход Delegated Proof-Of-Stake, реализованный в рамках платформы BitShares. Его основная идея в том, что блоки создаются не всеми узлами сети, а некоторым их подмножеством, определяемым путем голосования. Заранее детерминированный порядок генерации блоков, а также малое число узлов-генераторов дают возможность уменьшить интервалы между блоками с минут до двух-трех секунд и, как следствие, на порядок увеличить пропускную способность. Но децентрализованная архитектура все еще сильно проигрывает централизованной, и до объемов, например, системы Visa криптовалютам еще далеко. Однако ситуацию может исправить технология Lightening Network, позволяющая пересылать транзакции напрямую между контрагентами, сохраняя в блокчейне только «контрольные точки», по аналогии с банковскими страховыми депозитами. Lightening Network основывается на протоколе криптовалюты Bitcoin и имеет хорошие шансы стать его частью, войдя в экосистему блокчейна.

Второй вопрос, который постоянно требуется решать при организации сети блокчейна, — как обеспечить узлы дисковым пространством, необходимым для хранения данных, ведь блоки генерируются непрерывно. К счастью, объем растет линейно, но все же остается очевидным, что оптимизация в рамках одного узла не панацея. Например, автор открытой блокчейн-платформы Scorex предлагает решение Rollerchain [1] — хранение лишь заголовков блоков и некоторого фиксированного объема дополнительных данных, что на несколько порядков снижает требования к дисковому хранилищу узла. Другой подход — изменение топологии сети. В классической P2P-архитектуре для безопасного функционирования сети криптовалют необходимо, чтобы некоторое количество узлов хранили все блоки. Но ничто не мешает добавлять вспомогательные узлы, которые могут выполнять ограниченный набор операций. Хороший пример такого подхода — «легкие» клиенты, позволяющие исполнять транзакции только для одного блокчейн-аккаунта (аналог банковского счета). С другой стороны, объем данных, необходимый для работы такого клиента, очень мал, что позволяет устанавливать его, например, на смартфоны.

***

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

Литература

  1. Alexander Chepurnoy, Mario Larangeira, Alexander Ojiganovarxiv. Rollerchain, a Blockchain With Safely Pruneable Full Blocks. URL: https://arxiv.org/pdf/1603.07926v3.pdf (дата обращения: 18.12.2016).

Александр Соловьев (solovyov.a.g@gmail.com) — независимый эксперт в области распределенных систем (Москва).