Point Network

Point Network как комплексная реализация Web 3.0

Аннотация. Web 3.0, также известный как децентрализованный интернет, — это термин, обозначающий предполагаемую одноранговую сеть, работающую на определённом консенсусом наборе протоколов, открытую для всех, децентрализованную, прозрачную, нейтральную, не требующую разрешения, устойчивую к цензуре и сохраняющую конфиденциальность, которая потенциально может заменить текущее поколение интернет-протоколов благодаря улучшенной безопасности и конфиденциальности. Этот путь к Web 3.0 начался с таких приложений, как Tor, Bittorrent, Bitcoin, Ethereum и IPFS, а теперь расцвёл в огромное количество проектов под названием «Веб 3.0». Однако лишь немногие из них достигают этих желаемых свойств, поскольку, как правило, только некоторые компоненты достаточно децентрализованы. В данном документе описывается Point Network — набор программных компонентов и протоколов, которые предлагаются в качестве децентрализованной замены всех стандартных компонентов современного Интернета. Он включает в себя уровень консенсуса на основе блокчейна, децентрализованный уровень хранения данных, децентрализованные домены и идентификаторы, а также браузер с поддержкой web3, позволяющий пользователям получать прямой доступ к сети. В качестве примера того, как Point Network позволяет реализовать Web 3.0, мы приводим набор распространённых приложений Web 2.0, переосмысленных с помощью нашей архитектуры, таких как Point Mail, электронная почта со сквозным шифрованием, Point Social, социальная сеть, переделанная под Web 3.0, и другие. Таким образом, Point Network представляет значительные улучшения основных протоколов традиционного Интернета, которые могут быть реализованы в области конфиденциальности, безопасности, устойчивости к цензуре и прозрачности. Это в полной мере отвечает определённым критериям Web 3.0.

Введение

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

Небезопасные протоколы. Интернет изначально не был разработан с учётом требований безопасности [DeNardis, 2007]. Спустя десятилетия нам всё ещё приходится страдать от подхода «безопасность — на потом». Поставщики оборудования и программного обеспечения едва успевают за уязвимостями «нулевого дня» (0-day или zero-day), строки кода и количество зависимостей растут в геометрической прогрессии, а атаки становятся всё более изощрёнными [Dessouky et al., 2020].

Массовая слежка. Государственные спецслужбы, чтобы вести массовую слежку во имя национальной безопасности, намеренно снижают уровень защиты каждого человека, внедряя бэкдоры в оборудование и программное обеспечение [Lear, 2018], сохраняя найденные уязвимости «нулевого дня» для собственных нужд, вместо того чтобы помогать их исправлять [Moshirnia, 2018] [Slupska et al., 2021], и хранят личные файлы, электронную почту, фотографии, документы, картинки, звонки, геолокацию и историю просмотров в огромных государственных центрах обработки данных [Coddington, 2017]. Не только выяснилось, что этой информацией злоупотребляют государственные служащие в личных, карьерных и политических целях [Slobogin, 2007] [Anderson, 2019] [Snowden2019], но и стало очевидно, что даже особо секретная информация в спецслужбах не защищена от кражи1) [Shane et al., 2017] [Brevini, 2017], и если неограниченный доступ к полным архивам цифровой жизни миллиардов людей попадёт в чужие руки, последствия будут непредсказуемы.

Цензура. Коалиция крупнейших корпораций в киберпространстве, известная в просторечии как «большая четвёрка» (Google, Amazon, Facebook, Apple), пользуется беспрецедентным монопольным контролем над потоком информации [van der Schyff et al, 2020] [Nadler and Collins, 2017] [Hallam and Zanella, 2017] [Harris, 2020] [Hubbard, 2020], управляют непрозрачными судами с безымянными неизбираемыми судьями без эффективных механизмов обжалования, время от времени участвуют в синхронных мероприятиях по удалению аккаунтов в социальных сетях, также известных как «деплатформирование» (отлучение от платформ) [Rogers, 2020], и активно вмешиваются в социальный дискурс, цензурируя определённые темы, ссылки и хэштеги и используя искусственный интеллект для усиления одних голосов и подавления других [Gunitsky, 2015]. Альтернативные социальные медиа-платформы не могут решить проблему, потому что их «ахиллесова пята» — отказ в обслуживании со стороны хостинг-провайдеров2). Кроме того, их доменные имена могут быть отобраны в любой момент [Kopel, 2013] [Molloy, 2021].

В то время как легальные пути, выбранные общественными организациями и движениями, не привели к значительным изменениям в этих областях, технологи сосредоточились на попытках решить проблемы с помощью протоколов, алгоритмов и инструментов кибербезопасности и криптографии. Такие проекты, как Bittorrent, Tor Network, Bitcoin, Ethereum, Signal, IPFS и другие, объединяет дух возвращения власти пользователям Интернета через децентрализованные пиринговые сети. Общее видение того, каким должен быть Интернет, пронизывает их сообщества, и разработчики работают над воплощением данной идеи в жизнь с помощью этих проектов. Это видение глобальной сети, открытой для участия, свободной от цензуры, не требующей разрешения и сохраняющей конфиденциальность, получило название «Веб 3.0», или «децентрализованный интернет» [Alabdulwahhab, 2018].

Разработчики Point Network вдохновлены теми же идеалами и работают для достижения тех же целей. Мы считаем, что большинство элементов, необходимых для создания Web 3.0, уже изобретены, осталось только разработать несколько дополнительных компонентов и соединить их вместе.

В архитектуре сети Point Network есть несколько важнейших компонентов: 1) децентрализованные идентификаторы (в состав которых входят децентрализованные домены), 2) децентрализованное хранилище (в качестве которого используется Arweave), и 3) браузер с поддержкой web3 (Point Browser) в сочетании с локально работающим прокси (ZProxy). Для достижения наших целей мы объединили несколько дополнительных технологий и реализаций.

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

Архитектура Point Network

Обзор архитектуры

Ниже приведена архитектура сети Point Network (рис. 1).

Architecture Point Network
Рис. 1. Упрощенная архитектура Point Network

Point Dashboard (панель управления) осуществляет установку, обновление и управление остальным программным обеспечением; она также показывает пользователю состояние различных компонентов.

Point Browser — это форк браузера Mozilla Firefox, который настроен как клиент web 3.0, взаимодействующий с Point Node. В частности, он имеет жёстко закодированную настройку, которая заставляет все запросы проходить через порт локального прокси ZProxy. Point Browser также оснащён расширением Point Extension, которое позволяет использовать Point SDK в децентрализованных приложениях, отправляет уведомления, управляет окном подтверждения и т. д.

Point Core (Node) — это внутренняя часть, работающая на компьютере пользователя. Она содержит следующие модули:

Жизненный цикл запроса-ответа в Point Network

Типичный жизненный цикл комбинации «запрос-ответ» (request-response) в сети Point Network выглядит следующим образом (в качестве примера URL мы будем использовать https://example.point/user/mike).

DNS-запрос. Обычно браузер отправляет DNS-запрос на централизованный DNS-сервер, превращая буквенно-цифровое доменное имя в IP-адрес для следующего обращения. Однако в обычном Интернете3) нет домена example.point. Вместо этого, локально запущенный прокси ZProxy, который является частью программного обеспечения Point Network и чей локальный порт жёстко прописан в настройках Point Browser, перехватывает все запросы, включая DNS-запросы, и возвращает localhost для всех DNS-запросов.

HTTP-запрос. Далее браузер обычно обращается к серверу, используя предоставленный IP-адрес, с HTTP-запросом (опционально обёрнутым в SSL/TLS для шифрования трафика). HTTP-запрос включает в себя: имя хоста (hostname), путь к запрашиваемому файлу, тип метода (GET, POST и другие), переменные/тело (variables/body) и прочие метаданные. В случае с Point Network HTTP-запрос перехватывается ZProxy.

Подготовка хэша корневого каталога (root directory) и хэша файла маршрутизации (routes file). Из части запроса, содержащей имя хоста (example.point в нашем случае), ZProxy просматривает хранилище «ключ-значение» (key-value), прикреплённое к этому домену в смарт-контракте идентичностей (Identities + ZDNS), чтобы определить, какой хэш корневого каталога и хэш файла маршрутизации в настоящее время прикреплены к данному домену.

Маршрутизация запроса. В нашем примере запрошенный URL соответствует маршруту /user/:name, указывающему на user.zhtml внутри корневого каталога (а mike станет значением имени переменной шаблона). Если бы URL не соответствовал никакому маршруту, ZProxy попытался бы установить, соответствует ли он пути внутри корневого каталога, и в этом случае было бы возвращено (загружено) содержимое этого файла.

Рендеринг шаблона. Если файл заканчивается на .zhtml (как в нашем примере), он сначала проходит через рендерер ZHTML. ZHTML — это язык бэкенда, используемый в dApps Point Network, вдохновлённый шаблонизаторами, такими как Jinja. Результатом рендеринга ZHTML является HTML, который может обрабатываться браузером.

Специальные маршруты. Существует список специальных маршрутов, которые считаются зарезервированными для дополнительной функциональности. Например, существует группа маршрутов /_storage/{id}, которая при вызове на любом домене возвращает (загружает) файл из децентрализованного хранилища на основе предоставленного идентификатора.

Хранилище (Point Storage)

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

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

Блокчейн как хранилище. Далее в качестве хранилища для Web 3.0 рассматривался сам блокчейн. Некоторые децентрализованные социальные сети, такие как Steemit (или HIVE), пытались использовать его. Однако это создало дополнительные проблемы.

IPFS. В мае 2014 года Protocol Labs предложили IPFS, представляющую собой протокол и одноранговую сеть для хранения и обмена данными в распределённой файловой системе. В настоящее время она широко используется большим количеством dApps в качестве уровня хранения данных. В гибридной системе Ethereum + IPFS контент передаётся и хранится в сети IPFS, а в блокчейне сохраняется только его хэш, занимающий всего 32 байта. Это свойство известно как «адресация контента» («адресация содержимого», «контент-адресация», content-addressing) (см. ниже), когда файл идентифицируется не по изменяемому URL, а по хэшу его содержимого. Недостаток использования IPFS для Web 3.0 заключается в отсутствии стимулов для сети хранить и обслуживать данные. Например, если пользователь хочет опубликовать фотографии своих домашних животных в децентрализованной сети Facebook, ему придётся оставаться в сети, чтобы предоставлять этот контент, поскольку, предположительно, не так много участников будут заинтересованы в его хранении. Как только первоначальный пользователь выходит из сети (а он является единственным участником, хранящим этот контент), контент также выходит из сети и становится недоступным. Другие пользователи сети могут «прикрепить» контент, который они хотят помочь сохранить, когда оригинальный пользователь находится в офлайне, но, как уже упоминалось, IPFS не имеет стимулов для обеспечения того, чтобы контент Web 3.0 всегда был онлайн, что важно для надёжного функционирования децентрализованного Интернета.

Filecoin. Из-за отсутствия стимулов в IPFS, в 2017 году Protocol Labs объявила о начале работы над другим проектом под названием Filecoin, который позволит пользователям платить децентрализованным поставщикам хранения данных за размещение и обслуживание их контента, пока они находятся вне сети. Эта архитектура ближе, чем все предыдущие подходы, к идеальным требованиям к уровню хранения Web 3.0, однако у неё есть и несколько недостатков. Один из них заключается в том, что доказательства с нулевым разглашением (zero-knowledge proofs), необходимые для установления того, что поставщики хранилищ («майнеры хранения», storage miners) продолжают хранить файлы, требуют дорогостоящего оборудования, которое не по карману большинству пользователей, желающих стать «майнерами хранения», в результате чего снижается уровень цензуроустойчивости. Другая проблема заключается в том, что пользователям приходится заключать сделки с конкретными поставщиками услуг хранения, указывая период времени, в течение которого их файлы должны храниться. По истечении этого срока пользователи должны заключить новые сделки с другими поставщиками, чтобы продлить срок хранения. Если пользователи этого не делают, контент теряется, поскольку не в интересах поставщиков хранения продолжать использовать пространство для просроченного контента в отличие от новых сделок.

Arweave. Несмотря на то, что существует ряд других проектов, реализующих децентрализованное хранение данных, их обзор выходит за рамки данного документа. Постепенный обзор потенциальных кандидатов, от облачных хранилищ, до блокчейн, IPFS и Filecoin, помогает понять специфические требования, которые необходимы для уровня хранения Web 3.0. Благодаря этому становится очевидным, почему для уровня хранения данных Point Network в конечном итоге был выбран проект Arweave.

Arweave — это одноранговая сеть для децентрализованного хранения данных, описанная в Arweave Litepaper [Williams, 2018]. Она представлена как недорогое, высокопроизводительное, постоянное хранилище, и при этом есть несколько специфических свойств, которые делают её желательной для использования в качестве уровня хранения для Web 3.0.

TODO: описание преимуществ...

Это показывает, почему проект Arweave в конечном итоге был выбран в качестве уровня хранения данных для Web 3.0 в Point Network. Тем не менее, чтобы Arweave функционировал как таковой, его необходимо было расширить дополнительными уровнями функциональности и механизмами, которые описаны в следующих разделах.

Хранение и получение файлов

Поскольку Point Network использует сеть Arweave для хранения данных, подробности о том, как хранятся файлы, и информация о гарантиях доступности данных описаны в документе Arweave [Williams, 2018]. Однако со стороны Point Network есть дополнительные надстройки поверх стандартного механизма хранения Arweave, необходимые для создания уровня хранилища для Web 3.0.

Адресация контента. Некоторые децентрализованные сети хранения файлов, такие как IPFS, имеют встроенную возможность адресации содержимого. Это означает, что путь, по которому ссылаются на файл, его основной ID, является хэшем содержимого этого файла, что полезно для обеспечения целостности данных. С Arweave дело обстоит иначе, по крайней мере, со стороны внешнего API. Когда файл хранится, его хэш (который обозначается как data_root) является частью транзакции. Но в случае, когда нужно найти файл в сети, обычно используется не data_root, а txid — идентификатор транзакции, в которой этот файл был передан в сеть. Тогда нода Arweave или гейтвей (шлюз) Arweave возвращают данные из этой транзакции, если они у них есть.

Point Network использует схему адресации контента, где идентификатор каждого файла представляет собой 256-битный keccak256 (вариант SHA-3). Мы обходим проблему поиска по txid, добавляя к транзакции специальный тег с ключом __pn_chunk_X_Y (где X и Y — целые числа, представляющие текущую версию расстановки имён в наших экспериментальных тестах), и значение, являющееся хэшем файла. Затем Point Network сохраняет хэш файла в виде поля (переменной) bytes32 в Solidity. Когда файл нужно извлечь по его хэшу, сначала мы находим ID транзакции по ID хэша, запрашиваем GraphQL API контрагента хранилища Arweave, используя специальный тег, получаем список ID транзакций-кандидатов, в которых появился файл, и затем запрашиваем файл по txid.

Среда без доверия. Одним из распространённых случаев использования Arweave является загрузка или просмотр файла на основе его идентификатора транзакции при переходе в браузере к URL-адресу одного из шлюзов Arweave, например arweave.net. Однако при этом возникает доверие к шлюзу Arweave. Мы предполагаем, что ни узел Arweave, ни шлюз Arweave потенциально не могут быть доверены достоверным данным, возвращаемым на основе txid или хэша, или что транзакция, помеченная меткой для запрашиваемого хэша, действительно содержит файл, хэшированный на этот ID. Поэтому для сохранения целостности данных уровень хранения Point Network никогда не принимает возвращаемый файл вслепую. Он проверяет, соответствует ли хэш файла запрашиваемому хэшу. Если это не так, уровень хранения переходит к списку других потенциальных транзакций. Если ни одна из них не хэширует требуемое содержимое, он рассматривает файл как недоступный.

Чанкинг (разбивка на фрагменты — чанки). Мы определяем предельный размер фрагмента (чанка) как 262 144 байта = 256 кикибайт (КиБ). Если файл превышает лимит, мы не пытаемся загрузить весь файл в Arweave, а разбиваем его на чанки, исходя из лимита размера чанка, и загружаем их параллельно. Каждый чанк имеет свой ID, основанный на той же схеме хэширования, что и файл с содержимым этого чанка. Затем Point Network создаёт и загружает специальный чанк chunkinfo, содержимым которого являются сериализованные9) метаданные о файле (все идентификаторы чанков, собранные в дерево Меркла), включая полное описание дерева Меркла. Затем идентификатор этого chunkinfo становится идентификатором файла, по которому на него ссылаются. Чтобы отличить chunkinfo от файла или чанка, мы записываем несколько байтов пролога chunkinfo, что практически не встречается в начале обычного файла.

При извлечении происходит то же самое, но в обратном порядке: когда мы загружаем файл по его идентификатору, то с помощью пролога обнаруживаем, что вместо файла мы загрузили чанк chunkinfo. Затем мы разбираем его, извлекаем идентификаторы чанков, загружаем чанки, собираем их в полный файл и возвращаем его в качестве результата.

Оплата. Хранение файлов на блокчейне Arweave требует оплаты в родном токене Arweave — AR. Чтобы обойти эту проблему, была предложена и создана экосистема Arweave Bundlers, которая представляет собой участников сети (бандлеров), управляющих узлами Arweave с расширенной функциональностью. Во-первых, они гарантируют, что если платёж поступил, то данные будут добавлены в сеть (в «переплёт») и распространены (просидированы). Во-вторых, платёж может быть осуществлён не только при помощи токенов AR, но и в другой криптовалюте. В нашем случае платежи могут осуществляться с помощью собственного токена Point Network под названием POINT, который затем автоматически обменивается бандлерами на AR для оплаты стоимости хранения данных в Arweave.

Директории

Каталоги в Point Network представлены файлами с картой имён файлов и подкаталогов в качестве ключей и хэшами, указывающими на файлы, в качестве значений.

В текущей реализации каталоги представляют собой JSON-файлы, имеющие следующую структуру:

Реализация Point Storage должна иметь метод(ы), позволяющий(ие) обходить структуру каталогов, рекурсивно загружая подкаталоги и файлы.

Личные файлы

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

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

Альтернативной схемой может быть использование случайно сгенерированных AES-ключей, шифрование их с помощью открытого ключа идентификатора и добавление в начало каждого чанка/файла. Таким образом, клиент по-прежнему не обременён хранением ключей и всегда может извлечь ключи AES, расшифровав их с помощью криптографии с открытым ключом, хотя это увеличивает объём памяти, необходимой для хранения каждого чанка.

Файлы настроек

Клиент, используя вышеописанный алгоритм, преобразует данные в гарантию хранения и в пару ключей RSA (redkeys). Однако всё равно возникает вопрос, где должны храниться эти метаданные.

Мы предлагаем размещать их у тех же поставщиков услуг хранения данных, шифруя с помощью AES (см. раздел "Личные файлы"). Таким образом, клиентам нужно будет только отслеживать идентификатор этого файла (его можно хранить в блокчейне, зашифрованным с помощью AES или RSA), а если им придётся войти в Point Network на новом устройстве, эти данные будут загружены, расшифрованы и можно продолжать работу дальше. А поскольку данные реплицируются между несколькими провайдерами хранения, плюс тот факт, что файл зашифрован и провайдеры хранения не могут отличить его от обычных данных, снимается опасение, что провайдеры могут подвергнуть эти данные цензуре.

Аналогичным образом такую функцию можно распространить на все настройки и данные профилей пользователей Point Network. Эти настройки могут храниться в частном каталоге на Point Storage, и в случае необходимости входа в Point Network на новом устройстве, программное обеспечение загрузит каталог и применит настройки. Кроме того, реализовав упорядочивание последовательности файлов настроек, обновления к ним можно будет передавать между устройствами, синхронизируя их в режиме реального времени.

Сноски

1) ЦРУ потеряло сотни секретных документов в процессе утечки Vault 7, а 29-летний сотрудник АНБ Эдвард Сноуден смог незамеченным вынести сотни тысяч совершенно секретных документов до момента их публикации.

2) Ярким примером является отключение Parler [Otala et al., 2021] [Kierstead, 2021].

3) И наоборот, внутри Point Browser все соединения со стандартным интернетом прерваны. Содержимое адресуемого Web3 полностью изолировано от «старого интернета» подобно тому, как скрипты блокчейна (смарт-контракты) выполняются в средах, изолированных от «реального мира», настолько, что для получения любых данных из «внешнего мира» необходимы специальные «оракулы» и «оракульные сети».

4) Strasbourg data center: monitor the situation или Пожар в дата-центре вызвал сбои в интернете по всей Европе

5) Google is locking people out of documents, and you should be worried

6) По данным сайта Etherscan, объём хранилища, необходимого для синхронизированного полного узла Ethereum, превысил 500 ГБ.

7) $0.076/KB or $76,000/GB

8) Bitcoin Cash: a short-term data availability layer for ethereum?

9) Изначально мы предлагаем использовать JSON для всех описанных здесь сериализаций.