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

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

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

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

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

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

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

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

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

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

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

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

Одно из решений, принятое протоколом Codex — децентрализованным файловым хранилищем, разрабатываемым Институтом свободных технологий, — основано на «кодах стирания» (erasure coding). Коды стирания опираются на давнюю идею, известную как «коды Рида—Соломона», разработанные Ирвингом С. Ридом и Густавом Соломоном из MIT Lincoln Laboratory в 1960 году.¹

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

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

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

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

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

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

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

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

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

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

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

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

Codex реализует стратегию, начинающуюся с описанных ранее кодов Рида—Соломона — в частности, сильный алгоритм Рида—Соломона, при котором множество блоков данных из набора могут быть утрачены без невозможности восстановления всего набора. Это означает, что сеть способна допускать потерю нескольких блоков и по-прежнему быстро реконструировать весь массив. Это позволяет реализовать полосопропускно-эффективную технику «ленивого» восстановления.

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

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

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

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

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

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

14.3 Децентрализованные защищённые коммуникации

Эффективным государствам и сообществам необходимы не только безопасные и прозрачные (где это уместно) архивы, но и приватные рельсы, по которым члены сообщества могут коммуницировать. Члены сообщества могут желать обсуждать деловые стратегии, изобретения или идеи новых технологий и должны быть уверены в безопасности своих коммуникаций.

Более того, сообществам необходимы безопасные средства коммуникации для обсуждения политических вопросов. Тот факт, что блокчейн-сообщества и кибергосударства объединяют людей с в целом совпадающими политическими взглядами, не означает отсутствия важных политических разногласий. Люди должны иметь возможность обсуждать их конфиденциально, прежде чем они будут готовы сделать свои идеи публичными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проблема с общинной криптовалютой: если сообщество невелико, ценность сети ниже, а атака 51% — того типа, что мы обсуждали в предыдущей главе — более вероятна. Есть ли способ сочетать специфические преимущества общинной криптовалюты с безопасностью, обеспечиваемой глобальными валютами? Безусловно. Решение — «заякорить» общинную криптовалюту в более децентрализованных глобальных валютах, используя последние в качестве расчётного слоя.

Существует множество способов реализации этого. Например, общинную криптовалюту можно выпустить как токен второго уровня на Ethereum — аналогично POL от Polygon и ARB от Arbitrum, но, предположительно, меньшего масштаба. Один из подходов — выпуск монеты в форме ZK-роллапа, обсуждавшегося ранее в этой главе.

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

Родственная стратегия — заимствовать идею из протокола EigenLayer и «рестейкнуть» ETH в новый токен. В нашем примере с CMTY: сначала стейкаем ETH в сервисе ликвидного стейкинга вроде Lido, получая stETH (представляющий застейканный ETH). Тем самым вы помогли защитить сеть Ethereum и получаете за это вознаграждение — но теперь у вас есть чрезвычайно ценный токен — stETH. Можно затем взять stETH и рестейкнуть его в качестве слоя безопасности для CMTY. Таким образом, попытка захватить контроль над сетью CMTY обошлась бы колоссально дорого. Злоумышленнику пришлось бы потерять реальные застейканные активы в результате штрафных санкций.

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

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

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

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

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

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