В декабре прошлого года мы анонсировали сеть Waku .
Сеть Waku — это первая децентрализованная сеть, сохраняющая конфиденциальность и обеспечивающая защиту от атак типа «отказ в обслуживании» (DoS) для однорангового обмена сообщениями. Он направлен на повышение конфиденциальности и безопасности в одноранговой связи за счет внедрения инновационных протоколов и технологий.
Давайте углубимся в то, почему и что такое сеть Waku.
Источник
Если вы следили за Waku или Status , вы, вероятно, знакомы с происхождением Waku. Мобильное приложение Status было создано как суперприложение web3, портал в экосистему Ethereum, который использует три первоначальных столпа: Ethereum для консенсуса, Swarm для хранения и Whisper для общения.
Команда разработчиков Status попыталась создать Status с помощью Whisper, но этот протокол имел фундаментальные ограничения, особенно для устройств с ограниченными ресурсами, таких как мобильные телефоны. Waku родился как преемник Whisper, извлекая уроки из его недостатков и создавая масштабируемую одноранговую сеть связи, подходящую для мобильных устройств и браузеров.
Проблемы/Желаемые свойства
Ваку стремится преодолеть следующие проблемы:
- Обобщенный обмен сообщениями: Waku стремится предоставить протоколы и сеть, позволяющие передавать произвольную полезную нагрузку. Хотя Waku изначально создавался для приложения чата Status, цель состоит в том, чтобы быть достаточно обобщенным для создания любого децентрализованного коммуникационного или сигнального приложения на Waku.
- Эфемерный обмен сообщениями: Waku стремится решить проблему связи в реальном времени, целью которой является обеспечение приемлемой задержки, позволяющей одному или нескольким пользователям обмениваться небольшими порциями данных. В этом отличие от IPFS или других децентрализованных систем хранения, которые позволяют хранить большие объемы данных за счет задержки и скорости реагирования.
- Устойчивость к цензуре: Waku стремится предоставить устойчивое к цензуре решение, при котором внешние субъекты не смогут блокировать доступ пользователей к инфраструктуре Waku. Но также и для разработчиков приложений, которые смогут создавать с мышлением «нельзя сделать зло» , когда у них нет ключа к королевству и возможности деплатформировать своих пользователей.
- Забота о конфиденциальности: предоставить разработчикам приложений возможность действовать по принципу «нельзя делать зло» в отношении сбора данных и метаданных своих пользователей. Это означает, что даже если бы они захотели или были вынуждены, они или любая третья сторона не смогли бы собирать метаданные, такие как социальные графики или модели активности своих пользователей.
- Анонимность: аналогично конфиденциальности, это возможность пользователей не связывать личную информацию (PII) со своей деятельностью в сети Waku или с использованием приложения, использующего сеть. Здесь рассматриваются PII в отношении сети (IP-адрес), блокчейна (например, адреса Ethereum) и маршрутизации (корреляции сообщений).
- Устройства с ограниченными ресурсами: как упоминалось ранее, при разработке Waku стараются учитывать такие среды, как мобильные устройства и браузеры, чтобы дать разработчикам возможность создавать DApps для этих платформ и обеспечивать как можно больше свойств, перечисленных выше.
Масштабируемость: Waku стремится поддерживать миллионы пользователей, сохраняя при этом вышеуказанные принципы; это необходимо тщательно спроектировать и протестировать.
Все вышеперечисленные свойства означают, что при проектировании Waku необходимо преодолеть и другие проблемы:
- Защита DOS: гарантия того, что сеть не будет перегружена сообщениями, что приведет к загрузке пользователей, у которых меньше ресурсов, из сети.
- Устойчивость сети и стимулирование: как нам обеспечить достаточно ресурсов в сети, чтобы такие устройства, как браузеры и мобильные устройства, могли получить доступ к сети?
- Децентрализация. Чтобы реализовать эти свойства, Waku необходимо децентрализовать на нескольких уровнях. Как нам поддерживать справедливый уровень децентрализации, чтобы гарантировать сохранение этих свойств в течение долгого времени?
Сеть Ваку
Как сеть Waku помогает реализовать описанные выше свойства?
Давайте рассмотрим различные протоколы Waku, объединенные в сети, и то, как они позволяют нам добиться этого.
Одноранговое обнаружение
Чтобы любая одноранговая система была надежной и децентрализованной, должен существовать механизм поиска новых узлов или узлов в указанной системе, обычно называемый обнаружением узлов .
Waku использует Discv5, аналогичный Ethereum. В ENR были внесены незначительные улучшения, позволяющие узлу Waku рекламировать:
- шарды, в которых они работают (см. маршрутизация сообщений — шардинг )
протокол, который они включили
у них может быть альтернативный мультиадрес, например, для подключения браузера к указанному узлу через WebSocket.
Discv5 децентрализован, что может предотвратить потенциальные атаки Сивиллы, когда злоумышленник пытается окружить узел жертвы, чтобы получить манипулируемое представление о сети.
Это помогает обеспечить анонимность, конфиденциальность и устойчивость к цензуре.
Благодаря объявлению обслуживаемого протокола он позволяет мобильным телефонам и браузеру находить узлы, которые могут их обслуживать.
Маршрутизация сообщений — Gossipsub
Подобно Ethereum, Waku использует libp2p-gossipsub. Это приносит несколько преимуществ:
- улучшенная пропускная способность по сравнению с Whisper: в gossipsub узлы образуют группу соседей (сетку), которой они отправляют сообщения. Данный узел будет только пытаться поддерживать соединения и активно обмениваться сообщениями с другими узлами. Уменьшение количества раз, когда каждое сообщение загружается или скачивается.
- Надежность: gossipsub имеет встроенную избыточность, что обеспечивает достаточную надежность при работе в децентрализованной одноранговой сети, где ни одному узлу нельзя доверять в надежности или хорошем поведении.
Анонимность: поскольку узлы пересылают сообщения от других узлов в своей сетке, а в отдельных сообщениях отсутствуют метаданные (например, нет подписи в виде обычного текста), это обеспечивает справедливую анонимность, поскольку наблюдатель не может узнать, исходил или пересылался их сосед. сообщение. Это работает в сочетании с децентрализованным механизмом обнаружения одноранговых узлов, таким как Discv5.
Мы назвали использование Ваку сплетен, протокола и сети. Реле Ваку.
Маршрутизация сообщений — сегментирование
Одним из недостатков Gossipsub является то, что каждый узел сети получает и отправляет каждое сообщение сети с некоторым усилением. Можно видеть, как это ограничивает масштабируемость: нельзя ожидать, что весь трафик сети будет передаваться через домашнее подключение к Интернету.
Чтобы решить эту проблему, вместо одной сети gossipsub используется шардинг. Сеть Waku разделена на несколько отдельных подсетей маршрутизации сообщений или сегментов. В настоящее время сеть Waku разделена на восемь сегментов. Это означает, что любой пользователь приложения Waku будет ретранслировать трафик только одного сегмента или одной восьмой (приблизительно) всей сети.
Восемь изначально было небольшим произвольным числом. Наш теоретический анализ показывает, что сегмент может поддерживать около 10 тысяч активных пользователей, сохраняя при этом среднюю требуемую пропускную способность около 4 Мбит/с, что означает 80 тысяч для всей сети.
Мы работаем над дальнейшим моделированием, чтобы подтвердить наши предположения. Мы также привлекаем разработчиков и пользователей сети для проверки теории. Цель состоит в том, чтобы со временем увеличить количество шардов в сети.
Благодаря улучшениям, внесенным в Discv5, узлы могут знать, какие сегменты обслуживают другие узлы, прежде чем подключаться к ним.
Маршрутизация сообщений — автошардинг
Одна из проблем с сегментированием заключается в том, что пользователи и приложения должны знать, какой сегмент использовать.
Одно приложение может произвольно решить, какой сегмент оно хочет использовать, но это может потребовать много работы, особенно при добавлении новых сегментов. Это также еще одно решение, которое должен принять разработчик; мы предпочитаем сделать работу разработчика максимально простой. Это также позволяет разработчикам создавать приложения, которые распределяются по нескольким сегментам, не делегируя выбор сегментов пользователю.
Автошардинг — это простой протокол, который отправляет сообщения в сегмент на основе приложения.
Маршрутизация сообщений — реле RLN
Waku является универсальным и сохраняет конфиденциальность, что означает, что можно транспортировать любой вид полезной нагрузки. Следовательно, не существует строгого определения «спама». Независимо от того, содержит ли сообщение мем или заметку zk для частного DeFi , Waku даже не должен знать его содержание; метаданные и данные должны оставаться конфиденциальными.
Следовательно, существует риск того, что кто-то отправит в сеть гигабиты данных. Это может быть проблемой на разных уровнях:
- Использование пропускной способности: это может привести к перегрузке пропускной способности пользователя и повлиять на другие услуги (потоковая передача, стейкинг) или к неожиданному счету.
- Возможность подключения: если узлу не хватает пропускной способности для отправки/получения всех сообщений на уровне gossipsub, то его поведение может рассматриваться как неправильное другими узлами, которые могут отключиться от него.
- Надежность: если трафик превышает доступную пропускную способность, узел может не иметь возможности надежно отправлять и получать сообщения.
Другие ресурсы: использование памяти коррелирует с трафиком, как и дисковое пространство для службы хранилища.
Поэтому вместо того, чтобы определять, как выглядит «спамовое» сообщение, мы ввели ограничение скорости в сети, чтобы обеспечить добросовестное использование Waku, с ограничением использования полосы пропускания на каждый сегмент. Это делается с помощью RLN или обнулителя ограничения скорости, который ограничивает скорость сообщений, отправляемых данным издателем. В настоящее время она установлена на 1 мсг/с.
В сочетании с максимальным размером сообщения (150 КБ) и максимальным количеством издателей (80 000, подлежит уточнению), мы можем предположить максимальное использование полосы пропускания на каждый сегмент (около 10 Мбит/с).
Ограничивать ставки для издателей конфиденциальным и устойчивым к цензуре образом сложно; вот почему мы используем технологию с нулевым разглашением:
Пользователи передают свои учетные данные RLN в смарт-контракт (в настоящее время в тестовой сети Ethereum Sepolia).
Узлы отслеживают все зарегистрированные членства в контракте.
При отправке сообщения пользователь прикрепляет к сообщению подтверждение RLN с текущей эпохой (временная метка в секундах).
Узлы могут проверять доказательства, не имея возможности сопоставить адрес Ethereum пользователя (используемый в смарт-контракте) с отправляемым сообщением, сохраняя анонимность.
Если пользователь пытается отправить более 1 сообщения в секунду, узлы могут обнаружить это и удалить излишки сообщений или спам, защищая сеть.
Обслуживание преимущественно автономных устройств и устройств с ограниченными ресурсами
Наконец, чем Waku полезен для устройств с ограниченными ресурсами, таких как мобильные телефоны и веб-браузеры? Waku определяет ряд [протоколов запроса-ответа ( https://rfc.vac.dev/spec/10/#requestreply-domain ), позволяющих таким устройствам получать доступ к сети Waku без необходимости постоянно находиться в сети или потреблять большое количество пропускной способности, т. е. без участия в сети Waku Relay.
Протокол Light Push (ссылки на документацию) позволяет легкому клиенту отправлять сообщение для пересылки в сеть Waku Relay с подтверждением приема от удаленного узла. Протокол фильтра позволяет легкому клиенту подписаться на удаленный узел и запрашивать только подмножество сообщений вместо всех сообщений, передаваемых в сегменте.
Наконец, протокол хранилища позволяет легким клиентам и узлам ретрансляции получать исторические сообщения, которые могли быть пропущены.
Ценностное предложение сети Waku
Хотя мы определили желаемые свойства и технологию, важно понимать потенциальные варианты использования сети Waku. В настоящее время в этой проблеме описано несколько УТП (уникальных ценностных предложений), и мы будем документировать эту тему дальше. Некоторые заслуживающие внимания варианты использования выходят за рамки создания приложений для межмашинного или человеческого общения:
- DApps без инфраструктуры: объединение различных децентрализованных технологий (Waku, Ethereum, IPFS) для развертывания DApp без оплаты централизованному хостинг-провайдеру.
- Устойчивый к цензуре доступ к децентрализованной сети для легких клиентов: использование протоколов запроса-ответа позволяет легким клиентам получать доступ к вашей одноранговой сети, не полагаясь на централизованный цензурируемый веб-шлюз.
- Сигнальная сеть: используйте сеть Waku, чтобы найти других узлов и согласовать конкретные параметры, чтобы сформировать собственную одноранговую сеть, Waku или нет, с другими правилами (более высокий предел скорости и т. д.).
Мы уже пусты ?
Мы описали желаемые свойства Waku и то, как сеть Waku их обеспечивает. Означает ли это, что Waku устойчив к цензуре, приватен, устойчив и масштабируем? Не совсем.
Начальная загрузка — это компонент всех одноранговых сетей, которые мы не рассматривали: как новый узел находит другие узлы в сети? Мы используем технологию Ethereum для начальной загрузки (ENR + DNS Discovery). Однако эта технология могла бы быть более децентрализованной. Мы намерены улучшить этот потенциал примерно к концу 2024 или 2025 года.
В общем, сеть должна быть децентрализована для достижения желаемых свойств. Хотя некоторые технологии позволяют такую децентрализацию (и мы работаем над улучшением той части, которая этого не делает), у этой проблемы есть социальный компонент. Если команда Waku — единственная, кто управляет узлами, то сеть по своей сути не может считаться децентрализованной, следовательно, устойчивой к цензуре и т. д.
Чтобы решить эту проблему, нам нужно добиться внедрения сети Waku, чтобы мы могли создать хорошую базу операторов узлов и разработчиков, которые запускают узлы, не завися от команды Waku.
Мы активизировали эти усилия в прошлом году и продолжим в этом году. Другим аспектом является предоставление денежного стимула операторам узлов для запуска узлов, чтобы сеть могла стать самодостаточной. У нас нет такого протокола; мы строим первый PoC.
Сеть Waku играет здесь важную роль. Как только такой протокол станет доступен, потребуется общее (рыночное) место, где разработчики/пользователи и операторы смогут находить друг друга; Сеть Waku могла бы стать таким местом.
Заключение
Waku стремится обеспечить суверенную связь с конкретными объектами недвижимости. Сеть Waku является важной вехой на пути к достижению этой цели и созданию общей децентрализованной сети, на которой могут строиться разработчики, а мы можем добавлять больше протоколов. Хотя мы не можем сказать, что Waku — это все, чем он хочет быть сегодня, он уже не требует разрешений и децентрализован на нескольких уровнях.
Сейчас мы работаем не только над добавлением недостающих частей в протоколы, но и над тем, чтобы принять Waku, чтобы сделать его де-факто децентрализованным, обеспечивая каждому возможность сопротивления конфиденциальности и цензуре.
Если вы хотите присоединиться к сообществу единомышленников, стремящемуся обеспечить одноранговое общение миллионам пользователей, присоединяйтесь к Waku Discord или подписывайтесь на нас на X.
Подпишитесь на нашу ежемесячную рассылку , чтобы получать наши новости прямо на свой почтовый ящик.
Если вас интересуют технологии, ознакомьтесь с нашими открытыми вакансиями или получите некоторые из наших наград .
Вы также можете помочь нам сохранить децентрализацию, запустив собственный узел Waku!
