Nostr 2.0 может быть построен на основе Биткойн в качестве уровня 2, обеспечивая безопасное хранение данных вне сети, так же как Lightning Network обеспечивает мгновенные платежи вне сети в качестве уровня 2.
В этой статье объясняется, как ретранслятор Nostr синхронизирует свои данные, сохраняя при этом свою облегченную природу, позволяя пользователям выборочно удалять данные, которые недоступны в блокчейнах уровня 1. В то же время, по сравнению с хранением больших объемов данных в блокчейне Биткойн, из-за ограниченной емкости и скорости блоков Биткойн хранение данных с помощью реле Nostr может быть дешевле.
Следующий простой проект в области информатики улучшает свойства распределения сетей Nostr в соответствии со стандартизированным критерием теоремы CAP. CAP означает непротиворечивость, доступность и устойчивость к разделам.
**Nostr relay не знает, когда файл конфигурации неполный, реле не соответствует последовательности (C в теореме CAP). **
Реле не соответствует последовательности (C в теореме CAP)
Согласованность означает, что базы данных, синхронизированные на каждом компьютере, одинаковы. Ретрансляторы Nostr не могут выполнять синхронизацию с минимальным доверием, подобно тому, как блокчейны синхронизируют свои данные блок за блоком. В отличие от полных узлов Биткойн, база данных, хранящаяся в ретрансляторе Nostr, обычно неполна. Помимо слепого запроса всех сообщений, подписанных определенным пользователем, ретранслятор Nostr не может обнаружить недостающие данные.
Проблемы согласованности/синхронизации Nostr:
Если два пользователя загружают свои соответствующие сообщения в разные ретрансляторы Nostr, эти два пользователя могут не видеть сообщения друг друга, потому что Nostr не похож на блокчейн. В блокчейне каждый раз, когда появляется новая запись, все полные узлы будут синхронизировать блокчейн. Все полные узлы одновременно добавят эти данные в виде блока в свою цепочку блоков. Каждый полный узел в блокчейне Биткойн владеет точно таким же блокчейном.
Если мы хотим, чтобы пользователи Nostr всегда могли видеть сообщения друг друга, то всем ретрансляторам Nostr нужен способ определения недостающих данных в профилях пользователей, чтобы они могли запрашивать недостающие фрагменты у других ретрансляторов Nostr или пользователей.
Используйте еженедельные хэши корня Merkle и полного дерева для синхронизации ретранслятора Nostr
Примерно раз в неделю пользователи могут организовывать все свои сообщения в дерево Меркла.
Каждый лист в дереве Меркла содержит хэш сообщения, точно так же, как каждый лист в биткойне содержит хэш транзакции.
После того, как пользователь организовал весь свой профиль в дереве Меркла, он опубликует корень Меркла в OP_RETURN в цепочке ниже обычной транзакции Биткойн. Вот почему для работы Nostr 2.0 не требуется хард-форк блокчейна. OP_RETURN — это раздел под биткойн-транзакцией, который позволяет добавить небольшое примечание перед подписью отправителя.
Кроме того, пользователь хэширует все дерево и загружает его в цепочку вместе с корнем Merkle (в OP_RETURN). Корень Меркла — это просто хэш верхней ветви, а не всего дерева. Хэш всего дерева необходим для того, чтобы пользователи и ретрансляторы могли определить, отсутствуют ли данные профиля.
Чтобы получить хэш всего дерева, поместите корень Merkle в корень текстового файла. Затем поместите ветвь Merkle на строку ниже корня. Затем поместите листья Меркла в ряд под веткой. Как только дерево устроено, как описано, хешируйте его все сразу. Ниже приведен пример хэша всего дерева того, как будет выглядеть хэш всего дерева для дерева Меркла, показанного выше. Хеширование всего дерева (одновременное хеширование всех данных дерева Меркла)
Хэши корня Merkle и всего дерева выполняют две ключевые функции:
Корни Merkle позволяют пользователям и ретрансляторам загружать часть файла конфигурации за раз, например, загружать транзакцию без необходимости загружать весь блок.
Хеширование всего дерева позволяет пользователям и ретрансляторам узнать, не являются ли их сохраненные файлы конфигурации неполными. В отличие от корня Меркла, хэш всего дерева будет совпадать только в том случае, если у вас есть все биты в дереве Меркла.
Этот дешевый метод можно использовать для обновления всего конфигурационного файла еженедельно или с заданной пользователем периодичностью. Nostr по-прежнему будет работать, как и сейчас, но пользователи могут время от времени платить несколько сат за синхронизацию своих данных между ретрансляторами Nostr, если они хотят, чтобы их сообщения были видны всем пользователям.
Пользователи и ретрансляторы могут загружать сообщения для одной ветки за раз. После каждой ветки они хэшируют эту ветку с другой веткой, ближайшей к корню Меркла, чтобы проверить, соответствует ли она корню Меркла в цепочке (аналогично SPV). Если эти ветки хэшируются вместе, чтобы соответствовать корню Merkle, то они будут знать, что ветвь является частью профиля пользователя, даже если у них еще нет полного профиля пользователя. Пользователи могут загружать разные ответвления одного и того же файла конфигурации из множества разных магистралей Nostr, проверяя при этом действительность каждого ответвления и гарантируя, что загруженный файл конфигурации завершен.
Загрузка форков по одному предотвращает атаки с задержкой, которые могут вывести из строя многие распределенные сети, поэтому корни и форки Merkle используются в официальном документе Биткойн для защиты легких кошельков SPV.
**Почему корень Merkle не может функционировать как хеш целого дерева? **
** Если бы ретрансляторы Nostr зависели только от корня Меркла, они не смогли бы узнать, когда дерево Меркла будет завершено, поскольку каждая пара ветвей, ближайших к корню Меркла, будет хешироваться в один и тот же корень Меркла. **
Чтобы убедиться, что профиль пользователя завершен, ретранслятор или пользователь хэширует свое обновленное все дерево Меркла и проверяет, соответствует ли оно всему хэшу дерева в цепочке. Если хэши всего дерева совпадают, то пользовательские данные полны. Если хэш всего дерева не совпадает, то ретранслятор или пользователь может сообщить другим ретрансляторам свой последний номер листа и запросить отсутствующую ветвь до тех пор, пока хэш всего дерева не совпадет. Чтобы отслеживать все новые корни Merkle, добавляемые каждую неделю или около того, ретрансляторы Nostr должны стать полными узлами Биткойн. Ретрансляторам Nostr 2.0 косвенно платят за хранение блокчейна Биткойн при одновременном повышении безопасности Биткойн и Nostr.
Пределы хранения Nostr: практическое правило пользователя
Поскольку ретрансляторы имеют право выбирать, что хранить, в отличие от полных узлов Биткойн, ретрансляторы Nostr могут потерять некоторые пользовательские данные. Поэтому пользователям следует хранить данные на ретрансляторе Nostr только в том случае, если пользователи могут делать резервные копии локально. Самостоятельный сервис Web5 позволяет пользователям синхронизировать резервные копии со всеми своими локальными устройствами, что снизит риск для пользователей, которые обеспокоены использованием Nostr. В конце концов, только в блокчейне данные действительно неизменны. Тем не менее, Nostr — довольно безопасное гибридное решение, которое по-прежнему будет хорошо работать во многих приложениях. Компромиссы перечислены ниже:
Три уровня минимизации доверия
Уровень 1: неизменяемое и дорогое хранилище данных, которое чрезвычайно сложно подвергнуть цензуре. (Блоки в цепочке синхронизируют все полные узлы Биткойн)
Уровень 2: Изменяемое и дешевое хранилище данных, умеренно сложная цензура. (дерево Меркла вне сети и хеш в цепочке, синхронная ретрансляция Nostr по запросу)
Локальное хранилище данных, синхронизированное со всеми локальными устройствами, легко подвергается цензуре. (местная централизация)
Фундаментальные компромиссы между блокчейнами, основанными на консенсусе Накамото, и Nostr
**Чем больше ретрансляторов Nostr хранит данные для определенного адреса, тем сложнее подвергнуть эти данные цензуре. Это означает, что популярные данные, размещенные на многих ретрансляторах Nostr, могут быть сложнее подвергнуть цензуре, чем непопулярные данные, которые редко загружаются. **
** С другой стороны, блокчейн консенсуса Накамото предотвращает цензуру на основе возраста данных. Чем дольше данные существуют в блокчейне, тем сложнее их удалить с помощью атаки 51%. **
Поскольку мы можем проверить, принадлежат ли определенные форки конкретным пользователям, ретрансляторы Nostr могут получать оплату каждый раз, когда они передают пользователю небольшой фрагмент данных. Для этого пользователю необходимо загрузить головную часть блокчейна (как в SPV), чтобы иметь возможность выполнять типичные функции легкого кошелька. Пользователь будет использовать функциональность SPV легкого кошелька для получения конкретной транзакции из цепочки, которая будет включать корень Merkle профиля пользователя и хэш всего дерева в его OP_RETURN. Теперь пользователи могут платить ретранслятору за загрузку ветки профиля этого пользователя за веткой и проверять каждую ветку, хешируя их, чтобы они соответствовали корневому каталогу Merkle в цепочке.
Чтобы отправить сатс (наименьшую единицу биткойнов) на ретранслятор Nostr в обмен на предоставление данных, мы используем дизайн ZKCP Грегори Максвелла (известного разработчика Bitcoin Core) (условные платежи с нулевым разглашением). [1] Усовершенствованная версия ZKCSP: Proof of Retrievability [2] В сочетании с Lightning Network.
Согласно описанию в официальном документе ZKCSP:
«...нет необходимости в доверенной третьей стороне... Мы также внедрили протокол ZKCSP для случая доказательства возможности восстановления, когда клиент платит серверу за доказательство того, что данные клиента были правильно сохранены на сервере». [2]
Пользователь инициирует смарт-контракт Lightning с несколькими финансистами.
Пользователи отправляют запросы, подписанные финансистами, напрямую на реле Nostr, подключенные к этим финансистам.
Пользователи теперь инициируют конструкции ZKCSP, чтобы гарантировать, что реле Nostr получат оплату от финансистов только после доставки правильно запрошенных данных.
После выполнения шага 3 пользователь внесет поправки в исходный запрос, подписанный финансистом, прежде чем начать построение ZKCSP на шаге 4. Пользователь добавит дополнение поверх исходного запроса, указав сумму для вычета как из баланса пользователя, так и из баланса финансиста (они должны быть одинаковыми, плюс комиссия финансиста), которую пользователь затем добавит к исходному сообщению. содержание для подписи.
**Если пользователь указывает отправить больше сатоши, чем у него есть, или больше, чем финансист заморозил на этом ретрансляторе Nostr, то ретранслятор Nostr отклонит запрос, поскольку ретранслятор не сможет получить оплату. **
Таким образом, пользователи могут подключаться ко многим ретрансляторам Nostr, замораживая свои средства только с несколькими спонсорами. Аналогичный подход можно применить и к Lightning Network, где финансисты с минимальным доверием являются посредниками без разрешения между пользователями и продавцами. Обычные молниеносные переходы P2P также доступны в Nostr 2.0, но это может быть полезно при частых сбоях маршрутизации и балансировки каналов.
Разблокировка платного Nostr Relay из белого списка
Ретрансляторы Nostr могут внести определенные ключи в белый список, если они хотят хранить данные, просматриваемые всеми этими пользователями. Если ретрансляторы Nostr не могут внести в белый список пользователей, желающих сохранить данные, они сохранят любые отправленные им данные. Если пользователи всегда могут отправлять данные на реле бесплатно, то пользователям никогда не придется платить за реле Nostr. Nostr может предлагать платные варианты только в том случае, если у ретранслятора есть возможность отказаться от хранения данных, за которые нельзя заплатить. Бесплатные реле все еще существуют, но возможности платных реле в настоящее время не существует.
Вместо того, чтобы пытаться хранить все данные Nostr бесплатно, платный ретранслятор Nostr может использовать белый список для выборочного хранения всех данных, которые его платные пользователи просматривают ежедневно. Некоторые ретрансляторы Nostr будут продолжать работать по бесплатной модели, но в больших масштабах это не является устойчивым, поскольку большинство бесплатных ретрансляторов — это просто энтузиасты-энтузиасты. Внесение в белый список (даже если бы мы могли безопасно назначить открытый ключ каждому профилю Nostr), дающее ретранслятору Nostr возможность решать, какие данные хранить, было бы невозможно.
Один открытый ключ на профиль открывает функцию белого списка: биткойн-адрес становится вашим открытым ключом Nostr.
Эта система, наконец, позволяет нам назначать открытый ключ каждому файлу конфигурации.
Нет смысла создавать пользователям новые открытые ключи для каждого поста... так как все они связаны с их профилями! Это не то же самое, что биткойн-адрес. В отличие от Биткойна, наличие у пользователей нескольких открытых ключей в одном приложении не улучшает конфиденциальность.
**Открытый ключ профиля Nostr должен совпадать с открытым ключом биткойн-транзакции, содержащей недельный хэш (корень Merkle всех сообщений пользователя и хэш всего дерева). В отличие от пользователей Nostr, которые используют подписи Schnorr, для подписи им потребуется использовать биткойн-кошелек (мобильный кошелек/легкий кошелек или полный узел). **
Прелесть этого заключается в том, что каждая учетная запись Nostr будет представлена своим биткойн-адресом**, что означает, что пользователи могут отправлять платежи непосредственно на учетные записи Nostr, не запрашивая два разных открытых ключа. Это снижает когнитивные затраты новых пользователей в системе. Вместо использования имен пользователей пользователям по-прежнему необходимо отправлять друг другу открытые ключи или DNS, чтобы найти друг друга на Nostr. **
Если другие приложения Nostr используют разные открытые ключи, их все равно можно привязать к одному и тому же децентрализованному удостоверению (DID) — таким образом, способ идентификации вашей учетной записи остается единым для всех приложений. Однако это правило консенсуса Nostr будет ограничивать использование только одного открытого ключа для каждого профиля в каждом приложении Nostr.
DHT действует как таблица лидеров для открытия пиров.
Ретрансляторы могут использовать распределенную хэш-таблицу (DHT) для поиска других ретрансляторов. Ретрансляторы могут делиться своим белым списком в распределенной хеш-таблице, указав открытый ключ, в котором хранятся данные. Таким образом, ретрансляторы с отсутствующими разветвлениями данных для определенного открытого ключа могут сканировать DHT и напрямую подключаться к IP-адресам других ретрансляторов, утверждающих, что хранят эти отсутствующие разветвления. Затем ретрансляторы могут загружать отсутствующие ветки непосредственно с этих ретрансляторов Nostr.
Ретрансляторы также смогут находить наиболее активных ретрансляторов, проверяя, сколько предыдущих транзакций ZKCSP эти ретрансляторы разрешили в цепочке — недавние и все время. В этой системе все ретрансляторы Nostr становятся полноценными узлами, поэтому аудит предыдущих транзакций других ретрансляторов будет безболезненным. Это сделало бы фальсификацию доверия дорогостоящей, поскольку транзакции в сети всегда требуют комиссии за транзакцию. Если ретранслятор Nostr открывает много каналов, чтобы построить доверительные отношения с самим собой, чтобы завоевать доверие других ретрансляторов, ему придется каждую неделю платить большие комиссионные за транзакции, чтобы поддерживать фальшивую репутацию. После того, как злоумышленнику не удастся предоставить недостающую ветвь, тайм-аут приведет к отключению ретранслятора, так что это только временная, дорогостоящая атака (точно так же, как атака 51% является временной, дорогостоящей атакой).
DHT не такой анонимный, как майнинг, так как открытый ключ каждого ретранслятора Nostr будет указан рядом с IP-адресом в DHT, но это избавит ретрансляторы от необходимости слепо отправлять запросы по сети — в достаточно большом масштабе. будет перегружать сеть. Ретрансляторы Nostr, стремящиеся к большей конфиденциальности, могут использовать VPN или другую службу защиты IP.
Пользователи не будут иметь доступа к этой же системе доверия, потому что они не являются полными узлами. Однако пользователи могут на это положиться.
Любители косвенно связаны с сотнями ретрансляторов Nostr
Поскольку пользователи автоматически сохраняют все заголовки блоков в своих легких кошельках, пользователи могут видеть, кто является наиболее активным майнером. Майнеры, становящиеся финансистами, позволят пользователям отфильтровывать самых популярных майнеров, чтобы им не приходилось слепо привязывать средства к случайным финансистам, которые не имеют никакого отношения к жизнеспособности сети.
** Финансистам (майнерам) нужно только заблокировать свои спутники с ретранслятором Nostr, не передавая сами данные между пользователями и ретранслятором. ** Финансисту (майнеру) нужно просто подписать запрос пользователя, чтобы пользователь мог напрямую взаимодействовать со всеми реле Nostr, к которым подключен финансист — 4 шага для ZKCSP+Lightning, как указано выше.
в заключение
Сеть Lightning Network не существовала бы без блокчейна консенсуса Накамото Биткойн, поскольку пользователям негде было бы хранить объединенные доказательства транзакций вне сети.
Точно так же, как пользователи объединяют все эти транзакции Lightning Network вместе и помещают небольшие доказательства в блокчейн, мы объединяем все данные Nostr и помещаем небольшие доказательства в блокчейн. Точно так же, как Lightning Network обеспечивает мгновенные платежи на втором уровне, Nostr может обеспечить хранение данных на втором уровне без риска небезопасной боковой цепи. **
** Он использует тот же подход, что и Lightning Network, с консенсусным блокчейном Биткойн Накамото на первом уровне и Nostr+ZKCSP Lightning на втором уровне. **
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Nostr2.0: как уровень хранения данных в цепочке Биткойн Layer 2
Автор: Колби Серпа Составитель: DAOrayaki
Nostr 2.0 может быть построен на основе Биткойн в качестве уровня 2, обеспечивая безопасное хранение данных вне сети, так же как Lightning Network обеспечивает мгновенные платежи вне сети в качестве уровня 2.
В этой статье объясняется, как ретранслятор Nostr синхронизирует свои данные, сохраняя при этом свою облегченную природу, позволяя пользователям выборочно удалять данные, которые недоступны в блокчейнах уровня 1. В то же время, по сравнению с хранением больших объемов данных в блокчейне Биткойн, из-за ограниченной емкости и скорости блоков Биткойн хранение данных с помощью реле Nostr может быть дешевле.
Следующий простой проект в области информатики улучшает свойства распределения сетей Nostr в соответствии со стандартизированным критерием теоремы CAP. CAP означает непротиворечивость, доступность и устойчивость к разделам.
**Nostr relay не знает, когда файл конфигурации неполный, реле не соответствует последовательности (C в теореме CAP). **
Реле не соответствует последовательности (C в теореме CAP)
Согласованность означает, что базы данных, синхронизированные на каждом компьютере, одинаковы. Ретрансляторы Nostr не могут выполнять синхронизацию с минимальным доверием, подобно тому, как блокчейны синхронизируют свои данные блок за блоком. В отличие от полных узлов Биткойн, база данных, хранящаяся в ретрансляторе Nostr, обычно неполна. Помимо слепого запроса всех сообщений, подписанных определенным пользователем, ретранслятор Nostr не может обнаружить недостающие данные.
Проблемы согласованности/синхронизации Nostr:
Если два пользователя загружают свои соответствующие сообщения в разные ретрансляторы Nostr, эти два пользователя могут не видеть сообщения друг друга, потому что Nostr не похож на блокчейн. В блокчейне каждый раз, когда появляется новая запись, все полные узлы будут синхронизировать блокчейн. Все полные узлы одновременно добавят эти данные в виде блока в свою цепочку блоков. Каждый полный узел в блокчейне Биткойн владеет точно таким же блокчейном.
Если мы хотим, чтобы пользователи Nostr всегда могли видеть сообщения друг друга, то всем ретрансляторам Nostr нужен способ определения недостающих данных в профилях пользователей, чтобы они могли запрашивать недостающие фрагменты у других ретрансляторов Nostr или пользователей.
Используйте еженедельные хэши корня Merkle и полного дерева для синхронизации ретранслятора Nostr
Хэши корня Merkle и всего дерева выполняют две ключевые функции:
Этот дешевый метод можно использовать для обновления всего конфигурационного файла еженедельно или с заданной пользователем периодичностью. Nostr по-прежнему будет работать, как и сейчас, но пользователи могут время от времени платить несколько сат за синхронизацию своих данных между ретрансляторами Nostr, если они хотят, чтобы их сообщения были видны всем пользователям.
Пользователи и ретрансляторы могут загружать сообщения для одной ветки за раз. После каждой ветки они хэшируют эту ветку с другой веткой, ближайшей к корню Меркла, чтобы проверить, соответствует ли она корню Меркла в цепочке (аналогично SPV). Если эти ветки хэшируются вместе, чтобы соответствовать корню Merkle, то они будут знать, что ветвь является частью профиля пользователя, даже если у них еще нет полного профиля пользователя. Пользователи могут загружать разные ответвления одного и того же файла конфигурации из множества разных магистралей Nostr, проверяя при этом действительность каждого ответвления и гарантируя, что загруженный файл конфигурации завершен.
Загрузка форков по одному предотвращает атаки с задержкой, которые могут вывести из строя многие распределенные сети, поэтому корни и форки Merkle используются в официальном документе Биткойн для защиты легких кошельков SPV.
**Почему корень Merkle не может функционировать как хеш целого дерева? **
** Если бы ретрансляторы Nostr зависели только от корня Меркла, они не смогли бы узнать, когда дерево Меркла будет завершено, поскольку каждая пара ветвей, ближайших к корню Меркла, будет хешироваться в один и тот же корень Меркла. **
Чтобы убедиться, что профиль пользователя завершен, ретранслятор или пользователь хэширует свое обновленное все дерево Меркла и проверяет, соответствует ли оно всему хэшу дерева в цепочке. Если хэши всего дерева совпадают, то пользовательские данные полны. Если хэш всего дерева не совпадает, то ретранслятор или пользователь может сообщить другим ретрансляторам свой последний номер листа и запросить отсутствующую ветвь до тех пор, пока хэш всего дерева не совпадет. Чтобы отслеживать все новые корни Merkle, добавляемые каждую неделю или около того, ретрансляторы Nostr должны стать полными узлами Биткойн. Ретрансляторам Nostr 2.0 косвенно платят за хранение блокчейна Биткойн при одновременном повышении безопасности Биткойн и Nostr.
Пределы хранения Nostr: практическое правило пользователя
Поскольку ретрансляторы имеют право выбирать, что хранить, в отличие от полных узлов Биткойн, ретрансляторы Nostr могут потерять некоторые пользовательские данные. Поэтому пользователям следует хранить данные на ретрансляторе Nostr только в том случае, если пользователи могут делать резервные копии локально. Самостоятельный сервис Web5 позволяет пользователям синхронизировать резервные копии со всеми своими локальными устройствами, что снизит риск для пользователей, которые обеспокоены использованием Nostr. В конце концов, только в блокчейне данные действительно неизменны. Тем не менее, Nostr — довольно безопасное гибридное решение, которое по-прежнему будет хорошо работать во многих приложениях. Компромиссы перечислены ниже:
Три уровня минимизации доверия
Фундаментальные компромиссы между блокчейнами, основанными на консенсусе Накамото, и Nostr
**Чем больше ретрансляторов Nostr хранит данные для определенного адреса, тем сложнее подвергнуть эти данные цензуре. Это означает, что популярные данные, размещенные на многих ретрансляторах Nostr, могут быть сложнее подвергнуть цензуре, чем непопулярные данные, которые редко загружаются. **
** С другой стороны, блокчейн консенсуса Накамото предотвращает цензуру на основе возраста данных. Чем дольше данные существуют в блокчейне, тем сложнее их удалить с помощью атаки 51%. **
Поскольку мы можем проверить, принадлежат ли определенные форки конкретным пользователям, ретрансляторы Nostr могут получать оплату каждый раз, когда они передают пользователю небольшой фрагмент данных. Для этого пользователю необходимо загрузить головную часть блокчейна (как в SPV), чтобы иметь возможность выполнять типичные функции легкого кошелька. Пользователь будет использовать функциональность SPV легкого кошелька для получения конкретной транзакции из цепочки, которая будет включать корень Merkle профиля пользователя и хэш всего дерева в его OP_RETURN. Теперь пользователи могут платить ретранслятору за загрузку ветки профиля этого пользователя за веткой и проверять каждую ветку, хешируя их, чтобы они соответствовали корневому каталогу Merkle в цепочке.
Чтобы отправить сатс (наименьшую единицу биткойнов) на ретранслятор Nostr в обмен на предоставление данных, мы используем дизайн ZKCP Грегори Максвелла (известного разработчика Bitcoin Core) (условные платежи с нулевым разглашением). [1] Усовершенствованная версия ZKCSP: Proof of Retrievability [2] В сочетании с Lightning Network.
Согласно описанию в официальном документе ZKCSP:
«...нет необходимости в доверенной третьей стороне... Мы также внедрили протокол ZKCSP для случая доказательства возможности восстановления, когда клиент платит серверу за доказательство того, что данные клиента были правильно сохранены на сервере». [2]
После выполнения шага 3 пользователь внесет поправки в исходный запрос, подписанный финансистом, прежде чем начать построение ZKCSP на шаге 4. Пользователь добавит дополнение поверх исходного запроса, указав сумму для вычета как из баланса пользователя, так и из баланса финансиста (они должны быть одинаковыми, плюс комиссия финансиста), которую пользователь затем добавит к исходному сообщению. содержание для подписи.
**Если пользователь указывает отправить больше сатоши, чем у него есть, или больше, чем финансист заморозил на этом ретрансляторе Nostr, то ретранслятор Nostr отклонит запрос, поскольку ретранслятор не сможет получить оплату. **
Таким образом, пользователи могут подключаться ко многим ретрансляторам Nostr, замораживая свои средства только с несколькими спонсорами. Аналогичный подход можно применить и к Lightning Network, где финансисты с минимальным доверием являются посредниками без разрешения между пользователями и продавцами. Обычные молниеносные переходы P2P также доступны в Nostr 2.0, но это может быть полезно при частых сбоях маршрутизации и балансировки каналов.
Разблокировка платного Nostr Relay из белого списка
Ретрансляторы Nostr могут внести определенные ключи в белый список, если они хотят хранить данные, просматриваемые всеми этими пользователями. Если ретрансляторы Nostr не могут внести в белый список пользователей, желающих сохранить данные, они сохранят любые отправленные им данные. Если пользователи всегда могут отправлять данные на реле бесплатно, то пользователям никогда не придется платить за реле Nostr. Nostr может предлагать платные варианты только в том случае, если у ретранслятора есть возможность отказаться от хранения данных, за которые нельзя заплатить. Бесплатные реле все еще существуют, но возможности платных реле в настоящее время не существует.
Вместо того, чтобы пытаться хранить все данные Nostr бесплатно, платный ретранслятор Nostr может использовать белый список для выборочного хранения всех данных, которые его платные пользователи просматривают ежедневно. Некоторые ретрансляторы Nostr будут продолжать работать по бесплатной модели, но в больших масштабах это не является устойчивым, поскольку большинство бесплатных ретрансляторов — это просто энтузиасты-энтузиасты. Внесение в белый список (даже если бы мы могли безопасно назначить открытый ключ каждому профилю Nostr), дающее ретранслятору Nostr возможность решать, какие данные хранить, было бы невозможно.
Один открытый ключ на профиль открывает функцию белого списка: биткойн-адрес становится вашим открытым ключом Nostr.
Эта система, наконец, позволяет нам назначать открытый ключ каждому файлу конфигурации.
Нет смысла создавать пользователям новые открытые ключи для каждого поста... так как все они связаны с их профилями! Это не то же самое, что биткойн-адрес. В отличие от Биткойна, наличие у пользователей нескольких открытых ключей в одном приложении не улучшает конфиденциальность.
**Открытый ключ профиля Nostr должен совпадать с открытым ключом биткойн-транзакции, содержащей недельный хэш (корень Merkle всех сообщений пользователя и хэш всего дерева). В отличие от пользователей Nostr, которые используют подписи Schnorr, для подписи им потребуется использовать биткойн-кошелек (мобильный кошелек/легкий кошелек или полный узел). **
Прелесть этого заключается в том, что каждая учетная запись Nostr будет представлена своим биткойн-адресом**, что означает, что пользователи могут отправлять платежи непосредственно на учетные записи Nostr, не запрашивая два разных открытых ключа. Это снижает когнитивные затраты новых пользователей в системе. Вместо использования имен пользователей пользователям по-прежнему необходимо отправлять друг другу открытые ключи или DNS, чтобы найти друг друга на Nostr. **
Если другие приложения Nostr используют разные открытые ключи, их все равно можно привязать к одному и тому же децентрализованному удостоверению (DID) — таким образом, способ идентификации вашей учетной записи остается единым для всех приложений. Однако это правило консенсуса Nostr будет ограничивать использование только одного открытого ключа для каждого профиля в каждом приложении Nostr.
DHT действует как таблица лидеров для открытия пиров.
Ретрансляторы могут использовать распределенную хэш-таблицу (DHT) для поиска других ретрансляторов. Ретрансляторы могут делиться своим белым списком в распределенной хеш-таблице, указав открытый ключ, в котором хранятся данные. Таким образом, ретрансляторы с отсутствующими разветвлениями данных для определенного открытого ключа могут сканировать DHT и напрямую подключаться к IP-адресам других ретрансляторов, утверждающих, что хранят эти отсутствующие разветвления. Затем ретрансляторы могут загружать отсутствующие ветки непосредственно с этих ретрансляторов Nostr.
Ретрансляторы также смогут находить наиболее активных ретрансляторов, проверяя, сколько предыдущих транзакций ZKCSP эти ретрансляторы разрешили в цепочке — недавние и все время. В этой системе все ретрансляторы Nostr становятся полноценными узлами, поэтому аудит предыдущих транзакций других ретрансляторов будет безболезненным. Это сделало бы фальсификацию доверия дорогостоящей, поскольку транзакции в сети всегда требуют комиссии за транзакцию. Если ретранслятор Nostr открывает много каналов, чтобы построить доверительные отношения с самим собой, чтобы завоевать доверие других ретрансляторов, ему придется каждую неделю платить большие комиссионные за транзакции, чтобы поддерживать фальшивую репутацию. После того, как злоумышленнику не удастся предоставить недостающую ветвь, тайм-аут приведет к отключению ретранслятора, так что это только временная, дорогостоящая атака (точно так же, как атака 51% является временной, дорогостоящей атакой).
DHT не такой анонимный, как майнинг, так как открытый ключ каждого ретранслятора Nostr будет указан рядом с IP-адресом в DHT, но это избавит ретрансляторы от необходимости слепо отправлять запросы по сети — в достаточно большом масштабе. будет перегружать сеть. Ретрансляторы Nostr, стремящиеся к большей конфиденциальности, могут использовать VPN или другую службу защиты IP.
Пользователи не будут иметь доступа к этой же системе доверия, потому что они не являются полными узлами. Однако пользователи могут на это положиться.
Любители косвенно связаны с сотнями ретрансляторов Nostr
Поскольку пользователи автоматически сохраняют все заголовки блоков в своих легких кошельках, пользователи могут видеть, кто является наиболее активным майнером. Майнеры, становящиеся финансистами, позволят пользователям отфильтровывать самых популярных майнеров, чтобы им не приходилось слепо привязывать средства к случайным финансистам, которые не имеют никакого отношения к жизнеспособности сети.
** Финансистам (майнерам) нужно только заблокировать свои спутники с ретранслятором Nostr, не передавая сами данные между пользователями и ретранслятором. ** Финансисту (майнеру) нужно просто подписать запрос пользователя, чтобы пользователь мог напрямую взаимодействовать со всеми реле Nostr, к которым подключен финансист — 4 шага для ZKCSP+Lightning, как указано выше.
в заключение
Сеть Lightning Network не существовала бы без блокчейна консенсуса Накамото Биткойн, поскольку пользователям негде было бы хранить объединенные доказательства транзакций вне сети.
Точно так же, как пользователи объединяют все эти транзакции Lightning Network вместе и помещают небольшие доказательства в блокчейн, мы объединяем все данные Nostr и помещаем небольшие доказательства в блокчейн. Точно так же, как Lightning Network обеспечивает мгновенные платежи на втором уровне, Nostr может обеспечить хранение данных на втором уровне без риска небезопасной боковой цепи. **
** Он использует тот же подход, что и Lightning Network, с консенсусным блокчейном Биткойн Накамото на первом уровне и Nostr+ZKCSP Lightning на втором уровне. **