Десять барьеров на пути распределенных реестров

В январе 2009 года некто Сатоши Накамото представил миру Bitcoin, а затем эта криптовалюта и технология ее поддержки — блокчейн — пошли по пути взлетов и падений. После ряда лет появилось понимание того, что блокчейн можно применять шире: начали появляться платформы «следующего поколения» — Ethereum, Steem, Zcash и другие. В крупных компаниях увидели ценность блокчейна — его устойчивость, целостность и т. д. — и начали адаптировать эту технологию для различных отраслей, создав целый класс распределенных реестров и сформировав вокруг них ряд отраслевых консорциумов, в том числе R3 и Hyperledger. Распределенные реестры могут в различной степени отличаться от блокчейнов и иметь более легкую судьбу благодаря участию крупных игроков рынка. Тем не менее распределенным реестрам придется преодолеть много препятствий, чтобы стать по-настоящему эффективными и долговременными решениями.

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

10. Удобство применения: зачем?

Проблема. Нынешние распределенные реестры не имеют удобных интерфейсов, и без специальных знаний их сложно применять. Разумеется, это проблема любых новых технологий, и можно рассчитывать на ее решение в дальнейшем и, соответственно, на более широкое использование. В этом отношении можно вспомнить реляционные СУБД и последующее появление для них графических пользовательских интерфейсов. Интереснее рассмотреть другой вопрос: а что именно конечные пользователи хотят от распределенных реестров? Задачи, для которых сегодня применяется криптография, ясны всем: если вы хотите скрыть содержание беседы с кем-то, пользуйтесь шифрованием. А какие задачи и желания конечных пользователей могут выполнить распределенные реестры с их полной публичной верифицируемостью, отчетностью, неизменяемостью и т. д.?

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

9. Руководство: кто определяет правила?

Проблема. Преимущество распределенных реестров в том, что ни один объект цепочки не может контролировать решения, принимаемые сетью; в случае биткойнов, например, они генерируются или пересылаются между узлами, только если большинство равноправных участников сети согласятся, что такое действие разрешено. Процедура согласования становится уязвимой, когда у одного участника появляется слишком много полномочий, но по поводу таких децентрализованных сетей есть и более серьезный вопрос: кто изначально должен решать, какие действия разрешены? Все подобные сети подчиняются определенному набору правил, и выбор того, кто их разрабатывает, не менее важен, чем выбор тех, кто обеспечивает их применение.

Если рассматривать процесс разработки правил, то даже самые децентрализованные сети окажутся вполне централизованными. Что касается, например, Bitcoin, то темпы добавления новых узлов к цепочке, вознаграждение участников за фиксацию транзакций в реестре и многие другие параметры были установлены создателем криптовалюты и с тех пор не менялись. Единственный параметр, который пользователи предложили поменять, — размер блоков, что привело к многолетним бесплодным спорам. Между тем на сегодня Ethereum пережил уже четыре так называемых жестких форка своей сети — процедуры, после которой участников, по сути, вынуждают перейти на новую версию программного обеспечения для выполнения новых правил, составленных ведущими разработчиками системы. Эти уже почти регулярные коллапсы механизмов управления, лежащих в основе криптовалют, угрожают свести их преимущества на нет. Таким образом, проблема не только в том, что непонятно, как именно управлять реестрами, и что руководство на самом деле централизованное и непоследовательное, но и в отсутствии открытой информации о соответствующих механизмах и распределении. Требуется больше прозрачности, чтобы пользователи криптовалют могли принимать взвешенные решения о собственном уровне участия.

Возможные решения. Проведен ряд исследований, посвященных вопросам сохранения децентрализованности механизмов, обеспечивающих соблюдение правил, — в частности, механизму майнинга без возможности объединения усилий различных сторон. Но если говорить о распределенных реестрах общего назначения, то вопрос о том, как поощрять участников к правильному ведению реестра, остается открытым. Например, непонятно, кто, кроме крупных удостоверяющих центров, пожелает расходовать свои ресурсы на содержание сервера журналирования для проекта Certificate Transparency, который не предоставляет никаких вознаграждений за соблюдение правил.

Что касается выбора самих объектов, отвечающих за разработку правил, то здесь не предложено каких-либо решений. Существует «Клятва Сатоши», перечисляющая обязательства, которые, по мнению ее авторов, должен взять на себя любой создатель приложения на основе блокчейна, однако это не более чем рекомендации. В крупных проектах распределенных реестров, таких как R3 и Hyperledger, решения принимаются консорциумом, а создатели Certificate Transparency выбрали централизованный подход. Однако знания о сравнительных характеристиках различных механизмов руководства отсутствуют, и неясно, как они будут развиваться по мере роста популярности соответствующих платформ.

8. сравнение: какой реестр лучше?

Проблема. Bitcoin был первым, а сегодня альтернатив уже тысячи, и каждая со своими уникальными преимуществами. У Ethereum, например, более мощный язык скриптов и возможность сохранения состояния, Litecoin позволяет создавать блоки быстрее, чем Bitcoin, и каждое новое «первичное размещение монет» (initial coin offering, ICO) обещает очередные блестящие особенности. Существует также немало идей криптовалют с протоколами консенсуса, отличными от «доказательства выполнения работы» (proof of work), а также проекты на базе распределенных реестров, вообще не имеющие отношения к криптовалютам, — например, Certificate Transparency, R3 Corda и Hyperledger Fabric.

Трудность, возникающая в условиях все более плотного рынка, — в том, чтобы понять различия доступных решений и выбрать лучшее для конкретной задачи. Нужен ли вам блокчейн или достаточно обычной СУБД? А может, хватит и Excel? Какие именно качества реестра вам необходимы? Нужна ли, например, публичная верифицируемость? Если да, то для чего?

Возможные решения. В рамках недавних исследований изучались сравнительные характеристики различных криптовалют (например, создание блока в Bitcoin за десять минут и в Litecoin за 2,5 минуты) и влияние этих свойств на безопасность. Выяснилось, в частности, что один и тот же уровень защиты от так называемого эгоистичного майнинга (selfish mining) обеспечивается 37 блоками в Ethereum и 6 блоками в Bitcoin (ввиду относительно низкой скорости создания блоков в обеих платформах).

Что касается распределенных реестров в целом, недавно проводилось сравнение характеристик безопасности Certificate Transparency и Bitcoin. Согласно выводам, если бы нужно было выбирать между ними, то пришлось бы делать выбор между доверием к распределенной сети удостоверяющих центров и потребностью в неэффективной широковещательной рассылке сообщений с использованием протокола консенсуса, основанного на proof of work.

7. Управление ключами: как выполнять транзакции?

Проблема. За годы существования Bitcoin было немало случаев, когда пользователи теряли все свои цифровые деньги, так как выбрасывали жесткий диск, забывали пароль или не принимали необходимых мер по защите кошелька; в худшем из известных случаев потеря составила 7,5 тыс. биткойнов. В подобных ситуациях вернуть утраченное нельзя — из-за необратимости транзакций и невозможности расшифровки данных. Широко освещался пример, связанный с Decentralized Autonomous Organization — «умным» контрактом Ethereum, созданным в качестве механизма коллективного инвестирования. Для разрешения ситуации пришлось вмешаться разработчикам Ethereum, которые, чтобы возместить ущерб, настояли на очередном «хардфорке» системы.

Хотя подобные инциденты имеют серьезные финансовые последствия, они не удивляют, в связи с нерегулируемостью «мира Дикого Запада» криптовалют. Существуют предложения о расширении использования криптовалют — например, о включении биткойн-кошельков в дистрибутивы Linux, в результате чего они попадут в руки менее опытных пользователей, меньше подготовленных к упомянутым рискам. Поэтому необходимы более надежные решения, которые позволили бы избежать утраты и хищения ключей.

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

6. Гибкость: какими алгоритмами пользоваться?

Проблема. Как уже обсуждалось, во многих криптовалютах правила «спускаются сверху». Например, в Bitcoin адреса подсчитываются согласно жестко заданной процедуре — путем использования серии криптоалгоритмов, включая хеширование SHA-256, RIPEMD-160 и др. Ведущие разработчики Ethereum между тем готовятся перейти на протокол доказательства доли владения (proof-of-stake) — новый протокол консенсуса вместо нынешнего Ethhash. Когда протокол изменят, у участников не будет иного выбора, кроме как согласиться с этим, чтобы продолжать пользоваться криптовалютой.

Помимо проблем руководства, обусловленных жесткостью спецификаций, есть другие, связанные с тем, что криптоалгоритмы подвержены взлому. Со временем компьютеры станут достаточно мощными, чтобы взломать SHA-256, и это позволит любому переписать всю историю блокчейна, защищенную лишь хешированием. Когда такая опасность возникнет, у разработчиков, скорее всего, будет достаточно времени, чтобы перейти на более защищенные альтернативы, однако неплохо было бы уже сейчас предоставить пользователям варианты выбора, как это сделано с протоколами наподобие TLS. Но, как и в случае последнего, гибкость может позволить осуществлять опасные атаки, поэтому также нужны четкие разъяснения, как именно обеспечивается гибкость и с какими криптографическими примитивами поддерживается. Пожалуй, безопаснее будет не позволять пользователям выбирать из нескольких алгоритмов, а разрешать им выбирать протокол консенсуса для своих транзакций в зависимости от того, насколько они доверяют в сделках сторонам и операторам системы.

Возможные решения. Почти все криптовалюты характеризуются фактически нулевой гибкостью — для каждого криптоалгоритма существуют только одна допустимая реализация и единственный способ достижения консенсуса. Исключение, пожалуй, составляет лишь Ethereum, технически позволяющий в умном контракте закодировать любой криптоалгоритм (независимо от надежности) путем включения в него произвольной библиотеки. Тем не менее базовые криптомеханизмы проверки, выполняемой участниками сети для верификации транзакций, и протокол консенсуса заданы так же жестко, как и в других криптовалютах.

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

5. Интероперабельность: как взаимодействовать реестрам?

Проблема. Существуют идеи создания единого глобального распределенного реестра наподобие Интернета и платформы общего назначения, поддерживающей большинство известных реестров. Но все же более вероятно, что различные организации будут пользоваться разными реестрами в зависимости от своих конкретных потребностей. Например, финансовые приложения с большей вероятностью будут пользоваться платформами наподобие Corda и Hyperledger Fabric, а для случаев, когда нужна полная открытость, больше подойдет нечто вроде Bitcoin или Ethereum.

Чтобы реализовать обещанную распределенными реестрами перспективу изменения нынешнего ландшафта разрозненных скоплений данных, нужно обеспечить интероперабельность, позволив различным реестрам «общаться» друг с другом.

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

Вместе с тем известны попытки создать интерфейсы связи между распределенными реестрами и другими источниками данных, например, в рамках проектов Town Crier и Oraclize. Реестры Corda и Hyperledger Fabric поддерживают модульность на уровне протоколов — теоретически возможно взаимодействие между различными реализациями системы, но реальных попыток наладить такое взаимодействие еще не было.

4. Масштабируемость: зачем хранить все транзакции?

Проблема. В пункте 1 обсуждается «масштабирование» времени обработки транзакций по мере роста вычислительной мощности сети. Другая проблема в том, что с ростом популярности системы не должна сильно увеличиваться нагрузка на пользователей в части хранения данных, так как это повышает барьеры входа. Однако с точки зрения безопасности для систем с полной публичной верифицируемостью важно, чтобы записи из реестра не удалялись. Из-за этого требования, например, полный блокчейн в Bitcoin сейчас занимает около 200 Гбайт, ежедневно увеличиваясь почти на 150 Мбайт. То есть основная проблема — как обеспечить необходимый баланс.

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

Возможные решения. Существует разработка, благодаря которой биткойн-кошельки могут работать на смартфонах без хранения реестра целиком, — упрощенный клиент верификации платежей (Simplified Payment Verification, SPV). Такие клиенты получают от полноценных участников и хранят только заголовки блоков из блокчейна, а не все содержимое целиком. Заголовков достаточно для проведения проверки, позволяющей исключить двойное расходование. С помощью полноценного узла SPV-клиент удостоверяется только в том, что определенная транзакция была включена в блокчейн. Таким образом транзакции, в которых заинтересованы SPV-клиенты, раскрываются архивным узлам (хранящим весь реестр), а задачу предотвращения внесения двойного расходования в реестр доверяют майнерам. Такие клиенты получили широкое применение, однако их безопасность, с учетом упомянутых проблем приватности и доверия, оставляет желать лучшего.

Еще одна важная разработка, способная предотвратить включение лишних транзакций в реестр, — платежные каналы, реализованные, например, в сети Lightning. Чтобы открыть такой канал, две стороны создают транзакцию, которая используется для блокировки некоторого объема средств. Затем стороны могут совершить произвольное число транзакций друг с другом (что важно, не записывая их в реестр), а когда они готовы закрыть канал — по причине исчерпания средств или окончания взаиморасчетов, — то размещают для этого в блокчейне еще одну транзакцию. Таким образом, существенно снижается нагрузка на блокчейн по сохранению данных — единственная пара транзакций служит «представителем» произвольного количества денежных переводов. А поскольку эту процедуру можно использовать для разрешения споров, между сторонами сохраняется отсутствие необходимости доверять друг другу. Хотя этот метод представляется перспективным, четкого понимания характеристик безопасности и приватности платежных каналов пока нет.

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

3. Экономика: Как минимизировать затраты?

Проблема. Bitcoin и его протокол консенсуса на основе доказательства работы широко критикуют. В частности, утверждается, что экосистема Bitcoin расходует электричество, как целое государство, в связи с чем криптовалюту называют «экологической катастрофой».

В этой связи предложено огромное количество альтернативных протоколов консенсуса, часть из которых используется в альтернативных криптовалютах. Например, при использовании протокола proof of stake так называемые валидаторы должны доказывать наличие «доли» в системе путем совершения инвестиции, что служит экономическим фактором, удерживающим от формирования неверных блоков в нарушение правил (для сравнения, в Bitcoin для предотвращения так называемых атак Сивиллы, направленных против процесса майнинга, участники вынуждены расходовать дорогостоящее электричество). Разновидность доказательства доли владения, в которой инвестиция примерно соответствует накопленным за все время койнам, используется в Peercoin и Blackcoin. А в Ethereum в ближайшие два года планируется переход (то есть опять хардфорк) на собственную версию доказательства доли участия — протокол Casper, в котором инвестиция представляет собой страховой депозит, блокирующий часть койнов валидатора на определенный период времени. На блокчейн-платформе Intel Sawtooth Lake применяется протокол доказательства прошедшего времени (proof of elapsed time), опирающийся на защитную технологию SGX. Одно из популярных предложений на базе Bitcoin — Bitcoin-NG — состоит в том, чтобы ограничить использование доказательства работы путем выбора временного «лидера», который может быстро, без выполнения большого объема вычислений, засвидетельствовать индивидуальную транзакцию.

Возможные решения. Существуют десятки публикаций как по доработке существующих протоколов (особенно протокола доказательства долевого участия), так и с предложениями совершенно новых. Тем не менее на сегодня в подавляющем большинстве криптовалют используется какая-то форма proof of work.

Что касается реестров общего назначения, выбор альтернативных протоколов консенсуса для них растет и на сегодня включает и более традиционные, такие как двухфазный контроль завершения транзакции, PBFT (Practical Byzantine Fault Tolerance) и др. Они обычно эффективнее используемых в криптовалютах протоколов доказательства, но их минус в необходимости фиксированной группы известных участников. Само собой, нужны уточнения соответствующих компромиссов и обоснованные сравнения растущего числа протоколов консенсуса для оценки их преимуществ, обеспечиваемых в различных ситуациях.

2. Приватность: как защитить данные?

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

Даже в отношении анонимности еще много недоработок. В рамках ряда исследований продемонстрированы ограничения, присущие в этом отношении Bitcoin. Более новые платформы наподобие Monero и Zcach теоретически предоставляют более надежные гарантии анонимности, но их практический анализ еще не проводился — не исключено, что у них имеются свои слабые места.

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

В числе предложенных решений — проект Hawk, механизм на базе развитых средств криптографии, с помощью которого пользователи могут скрывать детали своих транзакций, но подтверждать для остальной части сети их действительность. Однако Hawk разработан специально для Ethereum, а что касается распределенных реестров в целом, вопрос гибкого обеспечения приватности в них без крупных затрат ресурсов остается открытым.

1. Масштабируемость: согласие всей сети?

Проблема. Пожалуй, самый большой минус полностью распределенных реестров — необходимость подтверждения действительности транзакций всеми узлами сети. В частности, распределенный реестр не масштабируется по пропускной способности. Другими словами, чем больше вычислительная мощность сети, тем хуже показатели пропускной способности и выше задержки. Из-за требования одобрения всеми участниками каждой транзакции, с ростом числа узлов увеличивается время ожидания. Одна из главных идей криптовалют, для которой введено это требование, — полная публичная верифицируемость: любой участник может самостоятельно проверить корректность работы системы, повторно воспроизведя все транзакции и получив удостоверения в отсутствии нарушений согласованных правил. Если только часть узлов удостоверяет части реестра, то полной верифицируемости не будет. Чтобы повысить пропускную способность и уменьшить задержку, нужен некий баланс, при котором нет полной репликации, но обеспечивается некоторая степень открытости и верифицируемости. Первое можно реализовать с помощью сегментирования — когда каждый участник обрабатывает транзакции только в пределах некоторого сегмента.

Возможные решения. Тема сегментирования пользуется большим вниманием исследователей и участников рынка — имеется ряд предложений в этой области. Например, в Corda участникам нужно достигать консенсуса только по транзакциям, имеющим к ним прямое отношение, а в Certificate Transparency вообще не требуется глобального консенсуса по содержанию реестра. Подобные подходы обеспечивают намного большую масштабируемость, но вызывают сомнения с точки зрения верифицируемости. К примеру, если только отдельные участники видят какие-то транзакции, то как другие могут быть уверены в том, что их транзакции подчиняются глобальному набору правил? А если такого набора правил нет, то можно ли обеспечить удовлетворение разумных требований целостности?

***

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

Сара Мейклджон (s.meiklejohn@ucl.ac.uk) — преподаватель, Университетский колледж Лондона.