14. Глубже в технологию

14.1 Предварительные замечания

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

При этом мы вовсе не претендуем на то, что предложим единственный способ проработать технические детали. На деле технологическое решение не одно: многообещающих технологий много — одни уже существуют, другие разрабатываются, третьи кто-нибудь вот-вот придумает. Наша цель — описать стратегии, которые нравятся нам самим, в том числе инструменты, созданные в Institute of Free Technology, попутно сказав несколько слов о технологиях, которые их вдохновили, и о том, каким мы сегодня видим технологический ландшафт.

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

14.2 Долговечные, устойчивые к коррупции, прозрачные архивы

В главе 5 мы подробно говорили о том, как важны для управления сообществами надёжные архивы. Как мы видели, архивы хранят историю правительственных решений, прав собственности, культуры и отношений с другими сообществами. Более того — мы видели и это, — есть основания утверждать, что архив первичнее сообщества и государства; во всяком случае, без архива ни сообщество, ни государство существовать не могут. Дальше — больше: если государство или сообщество не способно надёжно вести записи о собственных действиях, оно лишает своих членов возможности понять, не пора ли им на выход — не перестала ли администрация сообщества отвечать их ценностям. Точно так же, если записи недоступны, члены сообщества уже не могут разобраться, в какие отношения их сообщество вступило, какие действия предприняло и — опять же — верно ли оно ценностям сообщества.

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

Решение, на которое мы намекали в главе 5, — развернуть децентрализованные архивы, обладающие византийской отказоустойчивостью. Идея в том, что единой точки отказа не будет: чтобы уничтожить архив, пришлось бы вывести из строя огромную часть сети. Отдельные узлы сети могут стать мишенью, но сеть такие атаки переживёт. Конечно, это утверждение самого общего свойства. Пора перейти к деталям.

Вариантов распределённых архивов, безусловно, немало — в том числе сети децентрализованного хранения данных, такие как InterPlanetary File System, или IPFS (с ней связана криптовалюта Filecoin), Storj, Arweave и Sia. В некоторых из этих проектов есть отличные идеи, за которые мы ещё будем агитировать. Однако полного набора желаемых свойств на сегодня не предлагает ни один из них.

Начнём с ограничений, в которые может упереться децентрализованный файловый сервис. Одна из проблем, конечно, в том, что узлы в сети разного качества. Речь здесь о «железе», а железо отказывает часто, без предупреждения — и, кажется, норовит отказать в самый неподходящий момент. Одно из решений — как можно чаще реплицировать данные в разных местах сети. В пределе это означало бы воспроизводить всё на каждом узле. Но такая стратегия дико неэффективна, и вдобавок она работает на централизацию: держать всю информацию, нужную для жизни, скажем, кибергосударства, смогут только узлы очень большой ёмкости. Сеть свелась бы к горстке узлов, способных хранить данные в масштабах Amazon или Google.

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

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

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

Словом, потенциальных проблем немало, и тревожимся о них не мы первые. Разберём некоторые из этих опасений и посмотрим, как их пытались снять до нас.

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

Одно из решений — его использует Codex, протокол децентрализованного файлового хранения, разработанный в Institute of Free Technology, — опирается на erasure-кодирование (кодирование с восстановлением после стираний). Оно развивает давнюю идею — коды Рида — Соломона, которые в 1960 году создали сотрудники Лаборатории Линкольна (MIT) Ирвинг Рид и Густав Соломон. Их основополагающая статья называлась «Полиномиальные коды над некоторыми конечными полями» (Polynomial Codes Over Certain Finite Fields), а сама идея за прошедшие годы нашла массу применений — самое известное из них компакт-диски.¹

Суть в следующем. Чтобы выяснить, не пропал ли тот или иной фрагмент данных, не хочется всякий раз искать сами данные — или убеждаться в их отсутствии. Куда эффективнее вкрапить в данные немного служебной информации — если угодно, маркеры для нужных данных. Скажем, блок медицинских данных может идти в комплекте с кодом. Вы не ищете сами медицинские записи — вы ищете только маркер. Если вы запросили у узла маркер и не получили ответа, есть основания считать, что данные пропали — хотя бы на время. Может, узел вышел из строя. А может, носитель памяти повреждён «битовой гнилью». Что именно случилось — неважно; вам нужно лишь знать, что информация могла пропасть.

Разумеется, всё это работает лишь при условии, что опрашиваемый узел ведёт себя добропорядочно и не пытается вас обмануть: ведь можно выбросить данные, которые положено беречь, а маркер к ним оставить. Нужен какой-то механизм аудита.

Erasure-кодирование помогает обнаруживать потерю данных, но в децентрализованных системах, где возможны византийские сбои, одного этого может не хватить. Злонамеренные узлы способны пускаться на самые разные уловки, изображая, будто хранят информацию. Зачем им это? Возможно, они урезают расходы: хотят тратить меньше на хранение и трафик, но при этом получать плату за хранение данных. А возможно, их злой умысел политического толка — они участвуют в заговоре, цель которого в том, чтобы важная культурная или правовая информация бесследно исчезла из сети. Значит, информацию, которая якобы хранится, нужно время от времени прощупывать — проводить аудит.

В академической литературе эта проблема хорошо изучена и известна под разными именами, среди которых — доказательство ответственного хранения (proof of custody) и доказательство пространства-времени (proof of space-time). Большинство существующих решений строится на частой случайной выборке блоков данных по всему массиву. В ходе такой проверки узлы-хранители обязаны убедительно подтвердить: данные, которые они, по их словам, держат у себя, действительно при них.

Сегодня эти механизмы хорошо изучены и в целом делают то, что от них требуется, — но с парой оговорок. Первая — эффективность. Аудит данных, когда их перебирают строка за строкой, обходится в огромные вычислительные затраты. Дальше, в случае децентрализованных архивов встаёт вопрос: с чем сверять эти данные, чтобы убедиться в их точности? Централизованный реестр информации не годится — иначе и решение задачи выйдет централизованным: «официальная» запись стала централизованной, а значит, тут же превратилась в точку уязвимости. Вдобавок есть проблема, о которой мы уже говорили в этом разделе: иногда проверяемая информация приватна. Возьмите те же медицинские записи (или государственные тайны — что угодно). Хотелось бы пройти аудит, не раскрывая аудитору само хранимое содержимое.

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

Если описывать предельно абстрактно, доказательство с нулевым разглашением — это просто способ доказать, что вы владеете некой информацией или неким умением, не раскрывая самой информации и не пуская умение в ход. Заметьте: это сильнее, чем просто предъявить метку или код в подтверждение того, что данные хранятся. Это куда ближе к математическому доказательству того, что нужные данные действительно у вас.

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

Вот тут и приходят на помощь доказательства с нулевым разглашением. Допустим, мы хотим доказать вам, что наша программа умеет то, что мы о ней говорим, не отдавая при этом самого ценного (скажем, мы продаём программу для решения некой задачи). Сделать это можно так. Мы предъявляем доказательство: всякий, кто способен решить интересующую вас задачу — назовём её Задачей 0, это некое вычисление, — способен на это лишь при условии, что умеет выполнять определённую логически связанную с ней задачу (возможно, включающую целый набор подзадач). Назовём её Задачей 1. Повторим: Задача 1 и Задача 0 связаны математически; на языке информатики Задача 1 сводится к Задаче 0. Доказательство строится на испытании: нужно убедиться, что человек справляется с Задачей 1. А поскольку умение выполнить Задачу 1 влечёт за собой умение выполнить Задачу 0, мы можем (с разумной вероятностью) заключить, что он решил — или может решить — Задачу 0. Не забывайте: Задача 0 — та, что вам нужна. Именно за неё вы готовы платить. Другая задача сама по себе для вас ничего не стоит — кроме того, что она удостоверяет: с Задачей 0 мы справимся. Вы можете попросить нас выполнить столько таких вычислительно связанных задач, сколько потребуется, чтобы увериться: программа умеет то, что мы про неё говорим. По сути, вы бросаете нам один вызов за другим, а мы доказываем, что наша программа справляется с заявленными задачами.

Доказательства с нулевым разглашением бывают самыми разными. Нам ближе всего лаконичные неинтерактивные аргументы знания — более известные как zk-SNARK. Идея доказательств типа SNARK живёт в научной литературе уже не первый год, и они воплощены на практике — в протоколах вроде Zcash и в роллапах с нулевым разглашением (ZK-роллапах), которые протокол Ethereum использует в так называемых «приложениях второго уровня» (например, в протоколах вроде Polygon zkEVM). Протокол второго уровня здесь можно представлять как отдельный блокчейн: операции он выполняет быстро, а в качестве надёжного расчётного слоя использует более децентрализованный протокол первого уровня — такой как Ethereum.

Ключевое отличие zk-SNARK от стандартной процедуры доказательства с нулевым разглашением (вроде той, которой мы проверяли вымышленную программу-кладоискатель) в том, что zk-SNARK, как следует из самого названия, неинтерактивен. Иначе говоря, вам не нужно бросать вызов за вызовом, чтобы индуктивно выстроить доказательство знания. Идея в том, что общей опорной строки, которая есть и у доказывающего, и у проверяющего, достаточно, чтобы достичь вычислительного нулевого разглашения без всякого взаимодействия.² Неинтерактивность доказательства избавляет и от необходимости прямой связи между доказывающей и проверяющей сторонами. А значит, любой может взять доказательство zk-SNARK и проверить его с той же степенью уверенности, что и все остальные. Особенно это ценно для независимых третьих сторон, подозревающих, что доказывающий и проверяющий в сговоре. Наконец, неинтерактивные процедуры доказательства особенно удобны в блокчейн-протоколах: постоянные интерактивные запросы обходились бы слишком дорого в вычислительном отношении.

Чуть выше мы упомянули ZK-роллапы, которые применяются в протоколах второго уровня Ethereum. Они тоже полезны: вместо доказательства по каждой транзакции в отдельности они дают доказательства валидности целых пакетов транзакций. Это удобно, когда мы хотим опросить несколько баз данных, подтверждают ли они обладание определёнными данными, не требуя доказательства на каждый отдельный запрос. Пакетные запросы эффективнее.

До сих пор мы говорили об обнаружении сбоев и утверждали: потерю данных можно выявить несколькими способами. Безобидную потерю обнаруживает erasure-кодирование, злонамеренную — дистанционный аудит с помощью zk-SNARK. Но мало обнаружить, что данные пропали или повреждены. Встаёт вопрос: что вы будете с этим делать? Потерю данных нужно восполнять — и восполнять эффективно.

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

И всё же порой узлы уходят из сети насовсем, а данные портятся по множеству причин. Мы считаем, что лучше всего уравновесить эти соображения позволяет стратегия, известная как «ленивое восстановление» (lazy repair). Суть в том, что какое-то время потерю данных можно терпеть — избыточности в системе хватает; но когда потери переходят определённый порог, надо браться за ремонт и возвращать системе необходимый запас избыточности.

Стратегия Codex, к примеру, отталкивается от идеи из уже упомянутой работы Рида и Соломона — точнее, от усиленного алгоритма Рида — Соломона, который позволяет потерять несколько блоков данных, прежде чем весь набор станет невосстановимым. Это значит, что сеть терпит пропажу сразу нескольких блоков — и всё равно способна быстро воссоздать набор данных целиком. А потому мы можем применить экономную по пропускной способности, «ленивую» технику восстановления — ту самую, что описана выше. Идея проста: как только избыточность опускается ниже определённого порога, включается процедура ремонта. Скажем, если в норме поддерживается семь копий, потерю можно терпеть, пока копий не останется четыре; после этого запускается создание дополнительных блоков. Такая стратегия избавляет сеть от постоянной лихорадочной гонки — чинить каждый пропавший кусочек данных.

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

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

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

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

Одна из идей — выстроить стимулы так, чтобы за небольшие массивы данных они были очень высоки и снижались по мере того, как объём хранимого растёт. Можно ввести дополнительные стимулы за данные, которые слабо реплицированы в системе, или за данные, по какой-то причине приоритетные (первыми на ум приходят медицинские записи).

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

14.3 Децентрализованная защищённая связь

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

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

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

Может показаться, что защищённая связь у нас уже есть, — и отчасти это правда. Но у нынешней системы — сетей и технологий связи — есть серьёзные ограничения. Значительная часть инфраструктуры шифрованной связи жёстко централизована, со всеми вытекающими отсюда опасностями. Скажем, мы можем переписываться через Pretty Good Privacy (PGP), и это даёт нам защиту шифрованием военного уровня, — но точки отказа никуда не деваются. Сервер ключей, к примеру, размещён централизованно. Существующая сеть связи может отказаться передавать шифрованные сообщения. Или отказаться передавать шифрованные сообщения из конкретного источника. Наконец, даже когда мы пользуемся протоколами шифрованной связи, посторонние всё равно могут узнать, что общаемся именно мы.

Стоит задуматься, почему это важно. Порой метаинформация — кто с кем говорит — значит даже больше, чем сам предмет разговора. Из метаданных можно извлечь очень многое: сеть общающихся между собой людей, время их сеансов связи, довольно точное представление об объёме переданной информации; наконец, можно вычислить, кто находится в центре общающейся группы, — так сказать, её хаб. Это проблема для любых переговоров о политической стратегии, но и для деловых отношений тоже. Руководители компаний могут захотеть обсудить возможное слияние, не выдавая самого факта, что они друг с другом общаются.

Словом, трудностей здесь хватает. Едва ли не главная из них — возможность того, что узлы начнут придирчиво отбирать, какую информацию пропускать. Должна ли у узлов быть власть цензурировать поток информации в сети? Хочется надеяться, что нет; впрочем, цензура на децентрализованных узлах — явление отнюдь не неслыханное.³

Разумеется, у нас есть технологии шифрования, так что проблема не в том, что кто-то прочтёт наши сообщения и затем подвергнет их цензуре. Проблема в том, что нашу переписку могут цензурировать, исходя из её источника или пункта назначения. Кто-то может взяться отсекать узлы, принадлежащие правым, левым или политически нейтральным сообществам. Или блокировать сообщения, адресованные таким сообществам. Или вырезать сообщения определённого объёма — ведь объём выдаёт известную степень интереса к текущим политическим событиям. Способны ли узлы на такое? Ещё как — уже сегодня: ведь сообщениям приходится распространяться по сети, а значит, каждый узел этой сети отвечает за то, чтобы передавать пакеты пересылаемых данных дальше по сети.

К счастью, эти проблемы решают протоколы вроде Waku, разработанного Institute of Free Technology. Искомое — найти стратегию, при которой узлы сети передают сообщения вслепую: не видя ни содержания, ни источника, ни адресата, ни объёма информации. Как этого добиться?

Центральная идея Waku: пакеты информации, идущие по сети связи, инкапсулируются — упаковываются так, чтобы нельзя было узнать ни содержание, ни автора, ни получателя. Узлам остаётся просто передавать упакованную информацию дальше. Но как же скрыть метаданные?

Размыть их можно несколькими способами. Во-первых, чтобы замаскировать объём отправляемой информации, короткие сообщения дополняют «мусорными» данными. Длинные сообщения разбивают на пакеты. Все эти сообщения пойдут не напрямую из точки А в точку Б — их маршрут по сети будет случайным, слепым к конечному пункту назначения. Узлу нужно знать лишь одно: предназначена ли конкретная капсула именно ему. Это он может проверить, «пропинговав» её с помощью доказательств с нулевым разглашением. Если капсула адресована ему, она это подтвердит; если нет — подтверждения принадлежности не будет, и капсула отправится дальше, к другим узлам.

При всём этом информация, понятно, должна передаваться эффективно, и один из главных способов этого добиться — выстроить сеть как безмасштабную. Такие сети строятся вокруг нескольких плотно сплетённых хабов: каждый связан со множеством локальных узлов — а заодно и с другими центральными хабами. Безмасштабные сети такого рода хорошо знакомы нам из природы, наглядные примеры тому — человеческий мозг и сети авиасообщения. Скажем, у большинства авиакомпаний есть горстка узловых аэропортов, и каждый из них плотно связан с региональными. Сети такого устройства — их разбирает Дункан Уоттс в книге «Малые миры» (Small Worlds) — и порождают феномен «шести рукопожатий». Мало того что такие сети, судя по всему, сами собой складываются и в природе, и в человеческой деятельности, — они ещё и умопомрачительно эффективны с математической точки зрения.⁴

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

В конечном счёте эта стратегия — в том виде, в каком её воплощает Waku, — даёт гражданам сети приватный и защищённый способ общаться друг с другом, скрывая, кто с кем говорит, сколько информации передаётся, а при желании — и время сеанса связи. Главное же — у узлов сети не будет никакой возможности цензурировать то, что они передают: им не узнать ни содержания сообщения, ни его отправителя, ни получателя.

14.4 Криптовалюты и здравая денежная политика

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

Ничего удивительного тут нет. Глупо было бы предложить платформу для децентрализованного управления — и не приложить её к деньгам. У традиционных фиатных валют и традиционных финансов все изъяны, о которых мы говорили на протяжении книги: они создают централизованные точки отказа, открывают векторы для атак и притягивают коррупцию, как магнит. И будем честны: описание управления сообществами, минующее его фискальный сектор, вряд ли примут всерьёз. Вести денежную политику и регулировать финансовый сектор — одна из главных задач управления сегодня — и оставалась ею на протяжении тысячелетий.

Принципиальный вопрос здесь не в том, стоит ли децентрализованному, но кооперативному управлению пользоваться криптовалютами, а в том, какую форму криптовалют выбрать. Заострим вопрос: пользоваться ли блокчейн-сообществам готовыми, признанными во всём мире криптовалютами вроде BTC и ETH — или каждому сообществу чеканить собственные токены и вести дела в них? Ответ: а почему не то и другое разом?

Начнём с того, что любому блокчейн-сообществу было бы глупо не разрешить у себя хождение базовых криптовалют вроде BTC и ETH. С денежной точки зрения они — по крайней мере на момент, когда пишутся эти строки, — здравы: предложение BTC рано или поздно упрётся в жёсткий потолок в 21 миллион монет, а ETH, пока мы это пишем, временами уже дефляционен — в транзакциях сжигается больше ETH, чем выпускается в виде наград за стейкинг.⁵ К тому же чем шире валюта обращается и чем сильнее децентрализована криптовалютная сеть, тем она безопаснее. Мы уже обсуждали, какие исполинские ресурсы понадобились бы для успешной атаки на любую из этих сетей: пришлось бы либо скупить огромные майнинговые мощности (в случае BTC), либо отправить в стейкинг колоссальный объём ETH. Вдобавок узлы обоих протоколов уже разбросаны по всему миру. При таких достоинствах — зачем вообще заводить криптовалюту отдельного сообщества?

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

Беда криптовалюты, выпущенной сообществом, в том, что у небольшого сообщества и сеть будет стоить меньше, а значит, атака 51 % — из тех, что мы обсуждали в предыдущей главе, — всегда остаётся возможной. Можно ли сохранить преимущества монеты, заточенной под своё сообщество, и одновременно не потерять безопасность и надёжность, которые дают монеты вроде BTC и ETH? Конечно. Фокус в том, чтобы закрепить криптовалюту сообщества в более децентрализованных глобальных монетах — использовать их как своего рода расчётный слой.

Укоренить монету сообщества в протоколе вроде Ethereum можно по-разному: например, выпустить её как монету второго уровня — что-то наподобие POL у Polygon и ARB у Arbitrum, только, надо думать, поскромнее размахом. Так или иначе, одна из идей — выпустить монету в виде своего рода ZK-роллапа — из тех, о которых мы говорили выше в этой главе.

Идея вот в чём. Допустим, наше блокчейн-сообщество выпускает монету второго уровня под названием Community, сокращённо — CMTY. По сути это значит, что у нас появляется реестр второго уровня, который выполняет вычисления, хранит информацию, ведёт учёт транзакций и того, кто чем владеет в нашем сообществе. Но если это ZK-роллап, мы можем сделать ещё две вещи. Во-первых, доказательствами с нулевым разглашением подтверждать, что транзакции проводятся по заранее заданному своду правил. Во-вторых, собирать транзакции второго уровня в пакеты и периодически навсегда записывать их историю в сеть первого уровня — в нашем случае в блокчейн Ethereum. Так мы получаем лучшее из обоих миров: реестр, смарт-контракты и всё прочее служат именно нашему сообществу и его интересам, и мы можем предъявить доказательство, что все эти транзакции и вычисления корректны. А результаты транзакций при этом закрепляем в блокчейне Ethereum — и пользуемся его прочной защитой, которую, в частности, обеспечивает глобальный разброс его узлов.

Родственная стратегия — позаимствовать приём протокола Eigenlayer и отправить ETH в «рестейкинг» под новый токен. Если остаться при нашем примере с CMTY, это значит вот что: сначала вы ставите свой ETH в стейкинг через протокол вроде Lido — сервиса ликвидного стейкинга — и получаете stETH, токен, представляющий поставленный в стейкинг ETH. Тем самым вы отдали свой ETH на защиту сети и будете получать за это вознаграждение, но теперь у вас на руках токен — stETH, — и токен этот чрезвычайно ценен. Этот stETH можно затем отправить в рестейкинг — сделать из него слой безопасности для CMTY. Тогда попытка захватить контроль над сетью CMTY обойдётся крайне дорого: если за такое злоумышленникам начислят штрафы и поставленные в стейкинг активы придётся отдать, потери будут самые настоящие.

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

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

Признавая, что единственно верного подхода к блокчейн-технологиям нет, мы всё же можем предложить инструменты, которые сами считаем оптимальными для строительства таких сообществ. В этой главе мы уже упоминали Codex и Waku, а раньше — Status. Но об одной части стека технологий мы до сих пор не сказали ни слова — о Nomos. Мы так долго откладывали разговор о Nomos потому, что Nomos, в сущности, и есть то, о чём эта книга. Nomos — блокчейн первого уровня, оптимизированный для управления сообществами. Это платформа, задуманная как подспорье в строительстве блокчейн-сообществ, отвечающих тем требованиям, которые мы обсуждали на страницах этой книги.

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

Подробнее об элементах стека технологий, который предпочитаем мы, можно узнать на сайтах: Codex (https://codex.storage/), Waku (https://waku.org/), Nomos (https://nomos.tech/) и Status (https://status.app/). Тем, кого заинтересовали эти технологии и стоящие за ними принципы, может пригодиться и остальное портфолио Institute of Free Technology (https://free.technology/). Пользуйтесь этими технологиями — или проходите мимо, как сочтёте нужным.

Остаётся ещё несколько вопросов, которые нужно разобрать. Рекомендованные нами технологии, как и любые другие, не работают в пустоте. Они рассчитаны на людей — но на людей, которые придерживаются определённых ценностей. Ничего не выйдет, если мы не согласованы со своими технологиями, — а вернее сказать, если они не согласованы с нами. Есть, впрочем, и другие концептуальные вопросы, мимо которых не пройти: например, может ли что-нибудь по-настоящему «не требовать доверия» и может ли что-нибудь быть по-настоящему децентрализованным. К этим увлекательным вопросам мы и обратимся в следующей главе.

Примечания