Самый большой потенциал технологии блокчейна, как и в случае открытого исходного кода, связан с тем, что можно назвать сервисами «инфраструктуры базового уровня». Этим сервисам присущи следующие свойства.
░ Зависимость – существует множество других сервисов, функциональность которых тесно связана с сервисом базового уровня.
░ Высокий сетевой эффект – использование одного сервиса очень большими группами людей (или даже всеми) дает существенные преимущества.
░ Высокие затраты на переключение – человеку трудно переключаться с одного сервиса на другой.
Обратите внимание, что среди этих свойств не упоминается исключительная «необходимость» или «важность». Бывают и маловажные базовые уровни (например, RSS-каналы), и важные небазовые уровни (например, продукты питания). Сервисы базового уровня появились еще до зарождения цивилизации: в так называемые времена пещерных людей самым важным сервисом базового уровня был язык. Со временем сюда добавились дороги, право, почтовые и транспортные системы, в ХХ веке – телефонные сети и финансовые системы, а в конце прошлого тысячелетия – интернет. Новейшие сервисы базового уровня – почти полностью информационные: системы интернет-платежей, идентификация, системы доменных имен, центры сертификации, системы репутации, облачные вычисления, различные виды каналов данных и, вероятно, уже в ближайшем будущем – рынки прогнозирования.
Возможно, крайне взаимосвязанный и взаимозависимый характер этих сервисов через десять лет приведет к тому, что переключиться с одной системы на другую людям будет сложнее, чем сменить собственное правительство. Поэтому чрезвычайно важно выстроить эти сервисы правильно и проконтролировать, чтобы отдельные структуры не получили над ними слишком много власти. На сегодняшний день многие из таких систем выстроены очень централизованно, и отчасти это связано с тем, что создатели Всемирной паутины не сумели понять важность этих сервисов и включить их по умолчанию – поэтому даже сегодня большинство сайтов просят вас «войти в систему через Google» или «войти в систему через Facebook», а центры сертификации сталкиваются с такими проблемами[29].
░ Иранский хакер-одиночка взял на себя ответственность за кражу нескольких SSL-сертификатов крупнейших сайтов, в том числе Google, Microsoft, Skype и Yahoo.
░ Мнения экспертов по безопасности разделились: одни поверили заявлению хакера, у других возникли сомнения.
░ На прошлой неделе основная версия стала гласить, что это была атака, организованная государством, – предположительно при финансировании иранского правительства и под его руководством, – в результате которой был взломан реселлер сертификатов при американской компании Comodo.
░ 23 марта Comodo признала факт атаки, заявив, что восемью днями ранее хакеры заполучили девять поддельных сертификатов для входа на сайты Hotmail от Microsoft, Gmail от Google, службы интернет-звонков и переписки Skype и Yahoo Mail. Также к ним попал сертификат для сайта расширений Mozilla Firefox.
Почему бы центрам сертификации снова не стать децентрализованными, по крайней мере до уровня модели M-of-N?[30] (Заметьте, что случай гораздо более широкого использования M-of-N логически отделим от случая с блокчейнами, но блокчейны оказались хорошей платформой для запуска M-of-N.)
Рассмотрим конкретный сценарий использования – «идентификация в блокчейне». Что вам понадобится для идентификации? Простейший ответ: приватный и публичный ключи. Вы публикуете публичный ключ, который становится вашим идентификатором, и подписываете каждое сообщение приватным ключом посредством цифровой подписи, чтобы каждый мог быть уверен, что это сообщение написали именно вы (в этом контексте «вы» означает «объект, который владеет этим конкретным публичным ключом»). Однако здесь есть несколько проблем.
1. Что, если ваш ключ украдут и вам нужно будет перейти на новый?
2. Что, если вы потеряете свой ключ?
3. Что, если вы захотите сослаться на других пользователей по их именам, а не по случайным 20-байтовым строкам криптографических данных?
4. Что, если вы захотите использовать не только ключ, но и более продвинутый подход к обеспечению безопасности вроде мультиподписи?
Давайте разберем каждую проблему по отдельности. Начнем с четвертой. Для нее есть простое решение: вместо того чтобы требовать один конкретный тип криптографической подписи, ваш публичный ключ можно сделать программой, и тогда действительная подпись становится строкой, которая при вводе в программу вместе с сообщением возвращает 1. Теоретически в этой парадигме можно закодировать одноключевой, многоключевой или любой другой набор правил.
Но есть проблема: публичные ключи будут слишком длинными. Для ее решения можно внести изначальный «публичный ключ» в какое-то хранилище данных (например, в распределенную хеш-таблицу, если мы хотим децентрализации) и использовать хеш «публичного ключа» в качестве идентификатора пользователя. Для этого пока не требуются блокчейны – хотя в последних разработках по своей конструкции масштабируемые блокчейны не так уж сильно отличаются от распределенных хеш-таблиц. Вполне возможно, что лет через десять все виды децентрализованных систем, используемые в любых целях, случайно или намеренно сойдутся в какой-то масштабируемый блокчейн.
Перейдем к первой проблеме. Можно посмотреть на нее как на проблему отзыва сертификата: если вы хотите «отозвать» определенный ключ, как вы сможете убедиться, что об этом узнáют все, кому нужно? Ситуация может решиться сама собой с помощью распределенной хеш-таблицы, но тогда возникает другая проблема: если вы хотите отозвать ключ, то чем вы его замените? Если ваш ключ украден, он есть и у вас, и у злоумышленника, и никто из вас не сможет доказать, что именно он – настоящий владелец. Одно из решений – иметь три ключа, а затем, если один из них будет отозван, потребовать подписи от двух из них или от всех, чтобы утвердить следующий ключ. Но это приводит к проблеме «ничего на кону»: если злоумышленнику в конечном итоге удастся украсть все три ваших ключа в одной точке истории, он сможет имитировать историю назначения нового ключа, назначая оттуда дополнительные новые ключи, и ваша собственная история перестанет иметь силу. В этом случае помогут временны´е метки, и для этого понадобится блокчейн.
Для второй проблемы тоже хорошо подойдет хранение нескольких ключей и переназначение – и здесь блокчейн не нужен. На самом деле переназначение тоже не требуется; при грамотном использовании разделения секрета вы можете вернуть потерянный ключ, просто сохранив его в «осколках», – если вы потеряете один осколок, всегда можно использовать математику разделения секрета и восстановить его из других. Что касается третьей проблемы, здесь самое простое решение – реестры имен на основе блокчейна.