Nostr 2.0 може бути побудований на біткойнах як рівень 2, забезпечуючи безпечне зберігання даних поза мережею, так само як Lightning Network забезпечує миттєві платежі поза мережею як рівень 2.
У цій статті пояснюється, як ретрансляція Nostr синхронізує свої дані, зберігаючи при цьому свою легку природу, дозволяючи користувачам вибірково видаляти дані, які недоступні в блокчейнах рівня 1. У той же час, порівняно зі зберіганням великих обсягів даних у блокчейні Bitcoin, через обмежену ємність і швидкість блоків Bitcoin, може бути дешевше зберігати дані за допомогою ретрансляторів Nostr.
Наступний простий дизайн інформатики покращує властивості розподілу мереж Nostr за стандартизованим критерієм теореми CAP. CAP означає узгодженість, доступність і допуск до розділів
**Ретранслятор Nostr не знає, коли файл конфігурації неповний, реле бракує узгодженості (C у теоремі CAP). **
Реле не узгоджується (C у теоремі CAP)
Узгодженість означає, що бази даних, синхронізовані на кожному комп’ютері, однакові. Ретранслятори Nostr не можуть виконувати синхронізацію з мінімізованою довірою подібно до того, як блокчейни синхронізують свої дані блок за блоком. На відміну від повних вузлів Bitcoin, база даних, що зберігається ретранслятором Nostr, зазвичай неповна. Окрім сліпого запиту всіх публікацій, підписаних певним користувачем, ретрансляція Nostr не може виявити відсутні дані.
Проблеми Nostr Consistency/Sync:
Якщо два користувачі завантажують свої відповідні публікації в різні ретранслятори Nostr, ці два користувачі можуть не бачити публікації один одного, оскільки Nostr не схожий на блокчейн. У блокчейні щоразу, коли з’являється новий запис, усі повні вузли синхронізують блокчейн. Усі повні вузли додадуть ці дані як блок до свого блокчейну одночасно. Кожен повний вузол у блокчейні біткойн володіє тим самим блокчейном.
Якщо ми хочемо, щоб користувачі Nostr завжди могли бачити публікації один одного, тоді всім ретрансляторам Nostr потрібен спосіб ідентифікації відсутніх даних у профілях користувачів, щоб вони могли запитувати відсутні фрагменти в інших ретрансляторів або користувачів Nostr.
Використовуйте щотижневий корінь Merkle і повні хеші дерева для синхронізації реле Nostr
Приблизно раз на тиждень користувачі можуть організувати всі свої публікації в дерево Merkle.
Кожен аркуш у дереві Merkle містить хеш публікації, так само як кожен аркуш у Bitcoin містить хеш транзакції.
Коли користувач організує весь свій профіль у дерево Merkle, він опублікує корінь Merkle у OP_RETURN у ланцюжку під звичайною транзакцією Bitcoin. Ось чому для роботи Nostr 2.0 не потрібен хардфорк блокчейну. OP_RETURN — це розділ під транзакцією Bitcoin, який дозволяє додавати невелику примітку перед підписом відправника.
Крім того, користувач хешує все дерево та завантажує його в ланцюжок разом із коренем Merkle (у OP_RETURN). Корінь Merkle - це лише частина верхньої гілки, а не все дерево. Хеш усього дерева важливий для користувачів і ретрансляторів, щоб вони могли виявити відсутність даних профілю.
Щоб отримати хеш усього дерева, розмістіть корінь Merkle у корені текстового файлу. Потім покладіть гілку Меркле на лінію під корінь. Потім помістіть листя Merkle на рядок під гілкою. Після того, як дерево впорядковано, як описано, хешуйте його все відразу. Нижче наведено приклад гешу цілого дерева, як би виглядав геш цілого дерева для дерева Merkle, показаного вище. Хешування всього дерева (хешування всіх даних дерева Merkle одночасно)
Корінь Merkle та хеші цілого дерева забезпечують дві ключові функції:
Коріння Merkle дозволяють користувачам і ретрансляторам завантажувати частину конфігураційного файлу за раз, наприклад, мати можливість завантажувати транзакцію без необхідності завантажувати весь блок.
Хешування всього дерева дозволяє користувачам і ретрансляторам знати, чи збережені файли конфігурації неповні. На відміну від кореня Merkle, весь хеш дерева буде відповідати, лише якщо у вас є всі біти в дереві Merkle.
Цей дешевий метод можна використовувати для оновлення всього файлу конфігурації щотижня або з частотою, визначеною користувачем. Nostr працюватиме так само, як і зараз, але користувачі можуть час від часу платити певну суму за синхронізацію своїх даних між ретрансляторами Nostr, якщо вони хочуть, щоб їхні публікації бачили всі користувачі.
Користувачі та ретранслятори можуть завантажувати повідомлення для однієї гілки за раз. Після кожної гілки вони хешують цю гілку з іншою гілкою, найближчою до кореня Merkle, щоб перевірити, чи збігається вона з коренем Merkle у ланцюжку (подібно до SPV). Якщо ці гілки хешуються разом, щоб відповідати кореню Merkle, тоді вони знатимуть, що ця гілка є частиною профілю користувача, навіть якщо вони ще не мають повного профілю користувача. Користувачі можуть завантажувати різні гілки одного файлу конфігурації з багатьох різних каналів Nostr, одночасно перевіряючи дійсність кожної гілки та гарантуючи, що завантажений файл конфігурації повний.
Завантаження форків по черзі запобігає атакам із затримкою, які можуть вивести з ладу багато розподілених мереж, тому корені та форки Merkle використовуються в документі про біткойн для захисту легких гаманців SPV.
**Чому корінь Merkle не може функціонувати як хеш цілого дерева? **
**Якби реле Nostr залежало лише від кореня Меркла, вони не могли б знати, коли дерево Меркла було завершено, оскільки кожна пара гілок, найближчих до кореня Меркла, хешувала б той самий корінь Меркла. **
Щоб переконатися, що профіль користувача заповнений, ретранслятор або користувач хешують усе своє оновлене дерево Merkle і перевіряють, чи воно відповідає всьому хешу дерева в ланцюжку. Якщо всі хеші дерева збігаються, то дані користувача повні. Якщо весь хеш дерева не збігається, то ретранслятор або користувач може повідомити іншим ретрансляторам свій останній номер аркуша та запитати відсутню гілку, доки не збігається весь хеш дерева. Щоб відстежувати всі нові корені Merkle, які додаються приблизно щотижня, ретранслятори Nostr мають стати повними вузлами Bitcoin. Ретранслятори Nostr 2.0 опосередковано оплачуються за зберігання блокчейну біткойнів, одночасно підвищуючи безпеку біткойнів і Nostr.
Обмеження зберігання Nostr: емпіричне правило користувача
Оскільки ретранслятори мають право вибирати, що зберігати, на відміну від повних вузлів Bitcoin, ретранслятори Nostr можуть втратити деякі дані користувача. Таким чином, користувачі повинні зберігати дані лише на ретрансляторі Nostr, якщо користувачі можуть створювати резервні копії локально. Власна служба Web5 дозволяє користувачам синхронізувати резервні копії на всіх своїх локальних пристроях, що зменшить ризик для користувачів, які стурбовані використанням Nostr. Зрештою, тільки в блокчейні дані справді незмінні. Тим не менш, Nostr є досить безпечним гібридним рішенням, яке добре працюватиме для багатьох програм. Компроміси наведені нижче:
Три рівні мінімізації довіри
Рівень 1: незмінне та дороге сховище даних, яке надзвичайно важко піддати цензурі. (Блоки в ланцюжку синхронізують усі повні вузли Bitcoin)
Рівень 2: змінне та дешеве зберігання даних, помірно складна цензура. (дерево Merkle поза ланцюгом і хеш у ланцюзі, синхронне реле Nostr на вимогу)
Локальне зберігання даних синхронізується з усіма локальними пристроями, легко піддається цензурі. (місцева централізація)
Фундаментальні компроміси між блокчейнами на основі консенсусу Накамото та Nostr
**Чим більше ретрансляторів Nostr зберігають дані для певної адреси, тим важче цензурувати ці дані. Це означає, що популярні дані, розміщені багатьма ретрансляторами Nostr, може бути важче цензурувати, ніж непопулярні дані, які рідко завантажуються. **
**З іншого боку, консенсусний блокчейн Накамото запобігає цензурі на основі давності даних. Чим довше дані існують у блокчейні, тим складніше їх видалити за допомогою атаки 51%. **
Оскільки ми можемо перевірити, що певні форки належать конкретним користувачам, ретранслятори Nostr можуть платити щоразу, коли вони передають невеликий фрагмент даних користувачеві. Щоб досягти цього, користувачеві потрібно завантажити головну частину блокчейну (як у SPV), щоб мати можливість виконувати типові функції легкого гаманця. Користувач використовуватиме функцію SPV легкого гаманця, щоб отримати конкретну транзакцію з ланцюжка, яка включатиме корінь Merkle профілю користувача та весь хеш дерева в його OP_RETURN. Тепер користувачі можуть оплачувати ретрансляцію, щоб завантажувати профіль цього користувача гілку за гілкою та перевіряти кожну гілку, хешуючи їх відповідно до кореневої системи Merkle у ланцюжку.
Щоб надіслати сат (найменшу одиницю біткойна) до ретранслятора Nostr в обмін на надання даних, ми використовуємо дизайн ZKCP (умовні платежі без знань) Грегорі Максвелла (відомий розробник Bitcoin Core). [1] Удосконалена версія ZKCSP: підтвердження можливості відновлення [2] У поєднанні з Lightning Network.
Відповідно до опису білої книги ZKCSP:
«...немає потреби в надійній третій стороні...Ми також запровадили протокол ZKCSP для випадку підтвердження можливості відновлення, коли клієнт платить серверу за підтвердження того, що дані клієнта правильно зберігаються на сервері». [2]
Користувач ініціює інтелектуальний контракт Lightning з кількома фінансистами.
Користувачі надсилають запити, підписані фінансистами, безпосередньо до ретрансляторів Nostr, підключених до цих фінансистів.
Тепер користувачі ініціюють конструкції ZKCSP, щоб гарантувати, що ретранслятори Nostr отримають гроші від фінансистів лише після того, як правильно запитані дані будуть доставлені.
Після виконання кроку 3 користувач внесе зміни до оригінального запиту, підписаного фінансистом, перш ніж розпочати будівництво ZKCSP на кроці 4. Користувач додасть додатковий над початковим запитом, вказавши суму, яку потрібно вирахувати з балансу користувача та фінансиста (вони мають бути однаковими, плюс комісія фінансиста), яку потім користувач додасть до оригінального повідомлення вміст для підпису.
**Якщо користувач вказує надіслати більше Sat, ніж він володіє, або більше, ніж фінансист заморозив на цьому ретрансляторі Nostr, ретранслятор Nostr відхилить запит, оскільки ретранслятор не зможе отримати оплату. **
Таким чином, користувачі можуть підключатися до багатьох ретрансляторів Nostr, заморожуючи свої кошти лише з кількома донорами. Подібний підхід можна застосувати з Lightning Network, де фінансисти з мінімізованою довірою є посередниками між користувачами та продавцями без дозволу. Звичайні блискавичні стрибки P2P також доступні в Nostr 2.0, але це може бути корисним, якщо маршрутизація та балансування каналів часто дають збої.
Білий список Розблокування платного Nostr Relay
Ретранслятори Nostr можуть додати певні ключі до білого списку, якщо вони бажають зберігати дані, які переглядають усі ці користувачі. Якщо ретранслятори Nostr не можуть внести в білий список користувачів, які бажають зберігати дані, вони зберігатимуть усі надіслані їм дані. Якщо користувачі завжди можуть безкоштовно надсилати дані на ретранслятори, то їм ніколи не доведеться платити за ретранслятори Nostr. Nostr може запропонувати платні варіанти, лише якщо ретранслятор має можливість відмовитися від зберігання даних, за які не можна заплатити. Безкоштовні естафети все ще існують, але платні наразі не існують.
Замість того, щоб намагатися зберігати всі дані Nostr безкоштовно, платний ретранслятор Nostr може використовувати білий список для вибіркового зберігання всіх даних, які його платні користувачі переглядають щодня. Деякі реле Nostr продовжуватимуть працювати на безкоштовній моделі, але в найбільших масштабах це не є стійким, оскільки більшість безкоштовних реле є лише ентузіастами-ентузіастами. Білий список (навіть якби ми змогли безпечно призначити відкритий ключ для кожного профілю Nostr), що дає ретранслятору Nostr можливість вирішувати, які дані зберігати, було б неможливо.
Один відкритий ключ на профіль відкриває функцію білого списку: адреса Bitcoin стає вашим відкритим ключем Nostr.
Ця система нарешті дозволяє нам призначати відкритий ключ кожному конфігураційному файлу.
Користувачі не мають ніякої користі для створення нових відкритих ключів для кожної публікації... оскільки всі вони пов’язані з їхніми профілями! Це не те саме, що адреса Bitcoin. На відміну від Bitcoin, наявність у користувачів кількох відкритих ключів в одній програмі не покращує конфіденційність.
**Відкритий ключ профілю Nostr має збігатися з відкритим ключем транзакції Bitcoin, що містить щотижневий хеш (корінь Merkle усіх дописів користувача та весь хеш дерева). На відміну від користувачів Nostr, які використовують підписи Schnorr, їм потрібно буде використовувати біткойн-гаманець (мобільний гаманець/легкий гаманець або повний вузол) для підпису. **
Принадність цього полягає в тому, що кожен обліковий запис Nostr буде представлено своєю адресою Bitcoin,** що означає, що користувачі можуть надсилати платежі безпосередньо на облікові записи Nostr без запиту двох різних відкритих ключів. Це зменшує когнітивні витрати нових користувачів у системі. Замість використання імен користувачів, користувачам все одно потрібно надсилати один одному відкритий ключ або DNS, щоб знайти один одного на Nostr. **
Якщо інші програми Nostr використовують різні відкриті ключі, їх все одно можна приєднати до того самого децентралізованого ідентифікатора (DID) - таким чином спосіб ідентифікації вашого облікового запису залишається узгодженим у всіх програмах. Однак це правило консенсусу Nostr обмежить використання лише одного відкритого ключа на профіль у кожній програмі Nostr.
DHT діє як таблиця лідерів для виявлення однолітків.
Ретранслятори можуть використовувати розподілену хеш-таблицю (DHT) для пошуку інших ретрансляторів. Ретранслятори можуть ділитися своїм білим списком у розподіленій хеш-таблиці, перераховуючи відкритий ключ, де зберігаються дані. Таким чином ретранслятори з відсутніми розгалуженнями даних для певного відкритого ключа можуть сканувати DHT і підключатися безпосередньо до IP-адрес інших ретрансляторів, які стверджують, що зберігають ці відсутні розгалуження. Потім ретранслятори можуть завантажувати відсутні гілки безпосередньо з цих ретрансляторів Nostr.
Ретранслятори також зможуть знаходити найактивніші ретранслятори, перевіряючи, скільки попередніх транзакцій ZKCSP ці ретранслятори вирішили в ланцюжку - останніх і за весь час. У цій системі всі ретранслятори Nostr стають повними вузлами, тому перевірка попередніх транзакцій інших ретрансляторів буде безболісною. Це зробить формування довіри дорогим, оскільки транзакції в ланцюжку завжди вимагають комісії за транзакції. Якщо ретранслятор Nostr відкриває багато каналів, щоб створити довіру до себе, щоб завоювати довіру інших ретрансляторів, йому доведеться щотижня платити багато комісій за транзакції, щоб підтримувати фальшиву репутацію. Після того, як зловмиснику не вдасться надати відсутню гілку, тайм-аут призведе до відключення ретранслятора, тому це лише тимчасова, дорога атака (подібно до того, як атака 51% є тимчасовою, дорогою).
DHT не такий анонімний, як майнінг, оскільки відкритий ключ кожного ретранслятора Nostr буде вказаний поруч із IP-адресою в DHT, але це дозволить уникнути необхідності сліпо надсилати запити ретрансляторам через мережу – у достатньо великому масштабі. перевантажить мережу. Ретранслятори Nostr, яким потрібна більша конфіденційність, можуть використовувати VPN або іншу службу захисту IP.
Користувачі не матимуть доступу до цієї самої системи довіри, оскільки вони не є повними вузлами. Однак користувачі можуть на це покластися.
Лівничі опосередковано пов’язані з сотнями реле Nostr
Оскільки користувачі автоматично зберігають усі заголовки блоків у своїх легких гаманцях, користувачі можуть бачити, хто є найактивнішими майнерами. Майнери, які стають фінансистами, дозволять користувачам відфільтрувати найпопулярніших майнерів, щоб їм не довелося сліпо прив’язувати кошти до випадкових фінансистів, які не мають жодного відношення до життєздатності мережі.
**Фінансистам (майнерам) потрібно лише заблокувати свої Sats за допомогою реле Nostr, без передачі самих даних між користувачами та реле. **Фінансист (майнер) просто повинен підписати запит користувача, щоб користувач міг напряму взаємодіяти з усіма реле Nostr, до яких підключений фінансист - 4 кроки для ZKCSP+Lightning, як зазначено вище.
на завершення
Мережа Lightning Network не існувала б без консенсусного блокчейну Bitcoin Nakamoto, оскільки користувачам не було б де зберігати свої пакетні докази транзакцій поза мережею.
Подібно до того, як користувачі об’єднують усі ці транзакції Lightning Network і поміщають невеликі докази в блокчейн, ми об’єднуємо всі дані Nostr і додаємо невеликі докази в блокчейн. Подібно до того, як Lightning Network забезпечує миттєві платежі на другому рівні, Nostr може забезпечити зберігання даних на другому рівні без ризику незахищеного бічного ланцюга. **
**Він використовує той самий підхід, що й Lightning Network, із консенсусним блокчейном Nakamoto Bitcoin на першому рівні та Nostr+ZKCSP Lightning на другому рівні. **
Переглянути оригінал
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Nostr2.0: як рівень зберігання даних у ланцюжку Bitcoin Layer 2
Автор: Colby Serpa Упорядник: DAOrayaki
Nostr 2.0 може бути побудований на біткойнах як рівень 2, забезпечуючи безпечне зберігання даних поза мережею, так само як Lightning Network забезпечує миттєві платежі поза мережею як рівень 2.
У цій статті пояснюється, як ретрансляція Nostr синхронізує свої дані, зберігаючи при цьому свою легку природу, дозволяючи користувачам вибірково видаляти дані, які недоступні в блокчейнах рівня 1. У той же час, порівняно зі зберіганням великих обсягів даних у блокчейні Bitcoin, через обмежену ємність і швидкість блоків Bitcoin, може бути дешевше зберігати дані за допомогою ретрансляторів Nostr.
Наступний простий дизайн інформатики покращує властивості розподілу мереж Nostr за стандартизованим критерієм теореми CAP. CAP означає узгодженість, доступність і допуск до розділів
**Ретранслятор Nostr не знає, коли файл конфігурації неповний, реле бракує узгодженості (C у теоремі CAP). **
Реле не узгоджується (C у теоремі CAP)
Узгодженість означає, що бази даних, синхронізовані на кожному комп’ютері, однакові. Ретранслятори Nostr не можуть виконувати синхронізацію з мінімізованою довірою подібно до того, як блокчейни синхронізують свої дані блок за блоком. На відміну від повних вузлів Bitcoin, база даних, що зберігається ретранслятором Nostr, зазвичай неповна. Окрім сліпого запиту всіх публікацій, підписаних певним користувачем, ретрансляція Nostr не може виявити відсутні дані.
Проблеми Nostr Consistency/Sync:
Якщо два користувачі завантажують свої відповідні публікації в різні ретранслятори Nostr, ці два користувачі можуть не бачити публікації один одного, оскільки Nostr не схожий на блокчейн. У блокчейні щоразу, коли з’являється новий запис, усі повні вузли синхронізують блокчейн. Усі повні вузли додадуть ці дані як блок до свого блокчейну одночасно. Кожен повний вузол у блокчейні біткойн володіє тим самим блокчейном.
Якщо ми хочемо, щоб користувачі Nostr завжди могли бачити публікації один одного, тоді всім ретрансляторам Nostr потрібен спосіб ідентифікації відсутніх даних у профілях користувачів, щоб вони могли запитувати відсутні фрагменти в інших ретрансляторів або користувачів Nostr.
Використовуйте щотижневий корінь Merkle і повні хеші дерева для синхронізації реле Nostr
Корінь Merkle та хеші цілого дерева забезпечують дві ключові функції:
Цей дешевий метод можна використовувати для оновлення всього файлу конфігурації щотижня або з частотою, визначеною користувачем. Nostr працюватиме так само, як і зараз, але користувачі можуть час від часу платити певну суму за синхронізацію своїх даних між ретрансляторами Nostr, якщо вони хочуть, щоб їхні публікації бачили всі користувачі.
Користувачі та ретранслятори можуть завантажувати повідомлення для однієї гілки за раз. Після кожної гілки вони хешують цю гілку з іншою гілкою, найближчою до кореня Merkle, щоб перевірити, чи збігається вона з коренем Merkle у ланцюжку (подібно до SPV). Якщо ці гілки хешуються разом, щоб відповідати кореню Merkle, тоді вони знатимуть, що ця гілка є частиною профілю користувача, навіть якщо вони ще не мають повного профілю користувача. Користувачі можуть завантажувати різні гілки одного файлу конфігурації з багатьох різних каналів Nostr, одночасно перевіряючи дійсність кожної гілки та гарантуючи, що завантажений файл конфігурації повний.
Завантаження форків по черзі запобігає атакам із затримкою, які можуть вивести з ладу багато розподілених мереж, тому корені та форки Merkle використовуються в документі про біткойн для захисту легких гаманців SPV.
**Чому корінь Merkle не може функціонувати як хеш цілого дерева? **
**Якби реле Nostr залежало лише від кореня Меркла, вони не могли б знати, коли дерево Меркла було завершено, оскільки кожна пара гілок, найближчих до кореня Меркла, хешувала б той самий корінь Меркла. **
Щоб переконатися, що профіль користувача заповнений, ретранслятор або користувач хешують усе своє оновлене дерево Merkle і перевіряють, чи воно відповідає всьому хешу дерева в ланцюжку. Якщо всі хеші дерева збігаються, то дані користувача повні. Якщо весь хеш дерева не збігається, то ретранслятор або користувач може повідомити іншим ретрансляторам свій останній номер аркуша та запитати відсутню гілку, доки не збігається весь хеш дерева. Щоб відстежувати всі нові корені Merkle, які додаються приблизно щотижня, ретранслятори Nostr мають стати повними вузлами Bitcoin. Ретранслятори Nostr 2.0 опосередковано оплачуються за зберігання блокчейну біткойнів, одночасно підвищуючи безпеку біткойнів і Nostr.
Обмеження зберігання Nostr: емпіричне правило користувача
Оскільки ретранслятори мають право вибирати, що зберігати, на відміну від повних вузлів Bitcoin, ретранслятори Nostr можуть втратити деякі дані користувача. Таким чином, користувачі повинні зберігати дані лише на ретрансляторі Nostr, якщо користувачі можуть створювати резервні копії локально. Власна служба Web5 дозволяє користувачам синхронізувати резервні копії на всіх своїх локальних пристроях, що зменшить ризик для користувачів, які стурбовані використанням Nostr. Зрештою, тільки в блокчейні дані справді незмінні. Тим не менш, Nostr є досить безпечним гібридним рішенням, яке добре працюватиме для багатьох програм. Компроміси наведені нижче:
Три рівні мінімізації довіри
Фундаментальні компроміси між блокчейнами на основі консенсусу Накамото та Nostr
**Чим більше ретрансляторів Nostr зберігають дані для певної адреси, тим важче цензурувати ці дані. Це означає, що популярні дані, розміщені багатьма ретрансляторами Nostr, може бути важче цензурувати, ніж непопулярні дані, які рідко завантажуються. **
**З іншого боку, консенсусний блокчейн Накамото запобігає цензурі на основі давності даних. Чим довше дані існують у блокчейні, тим складніше їх видалити за допомогою атаки 51%. **
Оскільки ми можемо перевірити, що певні форки належать конкретним користувачам, ретранслятори Nostr можуть платити щоразу, коли вони передають невеликий фрагмент даних користувачеві. Щоб досягти цього, користувачеві потрібно завантажити головну частину блокчейну (як у SPV), щоб мати можливість виконувати типові функції легкого гаманця. Користувач використовуватиме функцію SPV легкого гаманця, щоб отримати конкретну транзакцію з ланцюжка, яка включатиме корінь Merkle профілю користувача та весь хеш дерева в його OP_RETURN. Тепер користувачі можуть оплачувати ретрансляцію, щоб завантажувати профіль цього користувача гілку за гілкою та перевіряти кожну гілку, хешуючи їх відповідно до кореневої системи Merkle у ланцюжку.
Щоб надіслати сат (найменшу одиницю біткойна) до ретранслятора Nostr в обмін на надання даних, ми використовуємо дизайн ZKCP (умовні платежі без знань) Грегорі Максвелла (відомий розробник Bitcoin Core). [1] Удосконалена версія ZKCSP: підтвердження можливості відновлення [2] У поєднанні з Lightning Network.
Відповідно до опису білої книги ZKCSP:
«...немає потреби в надійній третій стороні...Ми також запровадили протокол ZKCSP для випадку підтвердження можливості відновлення, коли клієнт платить серверу за підтвердження того, що дані клієнта правильно зберігаються на сервері». [2]
Після виконання кроку 3 користувач внесе зміни до оригінального запиту, підписаного фінансистом, перш ніж розпочати будівництво ZKCSP на кроці 4. Користувач додасть додатковий над початковим запитом, вказавши суму, яку потрібно вирахувати з балансу користувача та фінансиста (вони мають бути однаковими, плюс комісія фінансиста), яку потім користувач додасть до оригінального повідомлення вміст для підпису.
**Якщо користувач вказує надіслати більше Sat, ніж він володіє, або більше, ніж фінансист заморозив на цьому ретрансляторі Nostr, ретранслятор Nostr відхилить запит, оскільки ретранслятор не зможе отримати оплату. **
Таким чином, користувачі можуть підключатися до багатьох ретрансляторів Nostr, заморожуючи свої кошти лише з кількома донорами. Подібний підхід можна застосувати з Lightning Network, де фінансисти з мінімізованою довірою є посередниками між користувачами та продавцями без дозволу. Звичайні блискавичні стрибки P2P також доступні в Nostr 2.0, але це може бути корисним, якщо маршрутизація та балансування каналів часто дають збої.
Білий список Розблокування платного Nostr Relay
Ретранслятори Nostr можуть додати певні ключі до білого списку, якщо вони бажають зберігати дані, які переглядають усі ці користувачі. Якщо ретранслятори Nostr не можуть внести в білий список користувачів, які бажають зберігати дані, вони зберігатимуть усі надіслані їм дані. Якщо користувачі завжди можуть безкоштовно надсилати дані на ретранслятори, то їм ніколи не доведеться платити за ретранслятори Nostr. Nostr може запропонувати платні варіанти, лише якщо ретранслятор має можливість відмовитися від зберігання даних, за які не можна заплатити. Безкоштовні естафети все ще існують, але платні наразі не існують.
Замість того, щоб намагатися зберігати всі дані Nostr безкоштовно, платний ретранслятор Nostr може використовувати білий список для вибіркового зберігання всіх даних, які його платні користувачі переглядають щодня. Деякі реле Nostr продовжуватимуть працювати на безкоштовній моделі, але в найбільших масштабах це не є стійким, оскільки більшість безкоштовних реле є лише ентузіастами-ентузіастами. Білий список (навіть якби ми змогли безпечно призначити відкритий ключ для кожного профілю Nostr), що дає ретранслятору Nostr можливість вирішувати, які дані зберігати, було б неможливо.
Один відкритий ключ на профіль відкриває функцію білого списку: адреса Bitcoin стає вашим відкритим ключем Nostr.
Ця система нарешті дозволяє нам призначати відкритий ключ кожному конфігураційному файлу.
Користувачі не мають ніякої користі для створення нових відкритих ключів для кожної публікації... оскільки всі вони пов’язані з їхніми профілями! Це не те саме, що адреса Bitcoin. На відміну від Bitcoin, наявність у користувачів кількох відкритих ключів в одній програмі не покращує конфіденційність.
**Відкритий ключ профілю Nostr має збігатися з відкритим ключем транзакції Bitcoin, що містить щотижневий хеш (корінь Merkle усіх дописів користувача та весь хеш дерева). На відміну від користувачів Nostr, які використовують підписи Schnorr, їм потрібно буде використовувати біткойн-гаманець (мобільний гаманець/легкий гаманець або повний вузол) для підпису. **
Принадність цього полягає в тому, що кожен обліковий запис Nostr буде представлено своєю адресою Bitcoin,** що означає, що користувачі можуть надсилати платежі безпосередньо на облікові записи Nostr без запиту двох різних відкритих ключів. Це зменшує когнітивні витрати нових користувачів у системі. Замість використання імен користувачів, користувачам все одно потрібно надсилати один одному відкритий ключ або DNS, щоб знайти один одного на Nostr. **
Якщо інші програми Nostr використовують різні відкриті ключі, їх все одно можна приєднати до того самого децентралізованого ідентифікатора (DID) - таким чином спосіб ідентифікації вашого облікового запису залишається узгодженим у всіх програмах. Однак це правило консенсусу Nostr обмежить використання лише одного відкритого ключа на профіль у кожній програмі Nostr.
DHT діє як таблиця лідерів для виявлення однолітків.
Ретранслятори можуть використовувати розподілену хеш-таблицю (DHT) для пошуку інших ретрансляторів. Ретранслятори можуть ділитися своїм білим списком у розподіленій хеш-таблиці, перераховуючи відкритий ключ, де зберігаються дані. Таким чином ретранслятори з відсутніми розгалуженнями даних для певного відкритого ключа можуть сканувати DHT і підключатися безпосередньо до IP-адрес інших ретрансляторів, які стверджують, що зберігають ці відсутні розгалуження. Потім ретранслятори можуть завантажувати відсутні гілки безпосередньо з цих ретрансляторів Nostr.
Ретранслятори також зможуть знаходити найактивніші ретранслятори, перевіряючи, скільки попередніх транзакцій ZKCSP ці ретранслятори вирішили в ланцюжку - останніх і за весь час. У цій системі всі ретранслятори Nostr стають повними вузлами, тому перевірка попередніх транзакцій інших ретрансляторів буде безболісною. Це зробить формування довіри дорогим, оскільки транзакції в ланцюжку завжди вимагають комісії за транзакції. Якщо ретранслятор Nostr відкриває багато каналів, щоб створити довіру до себе, щоб завоювати довіру інших ретрансляторів, йому доведеться щотижня платити багато комісій за транзакції, щоб підтримувати фальшиву репутацію. Після того, як зловмиснику не вдасться надати відсутню гілку, тайм-аут призведе до відключення ретранслятора, тому це лише тимчасова, дорога атака (подібно до того, як атака 51% є тимчасовою, дорогою).
DHT не такий анонімний, як майнінг, оскільки відкритий ключ кожного ретранслятора Nostr буде вказаний поруч із IP-адресою в DHT, але це дозволить уникнути необхідності сліпо надсилати запити ретрансляторам через мережу – у достатньо великому масштабі. перевантажить мережу. Ретранслятори Nostr, яким потрібна більша конфіденційність, можуть використовувати VPN або іншу службу захисту IP.
Користувачі не матимуть доступу до цієї самої системи довіри, оскільки вони не є повними вузлами. Однак користувачі можуть на це покластися.
Лівничі опосередковано пов’язані з сотнями реле Nostr
Оскільки користувачі автоматично зберігають усі заголовки блоків у своїх легких гаманцях, користувачі можуть бачити, хто є найактивнішими майнерами. Майнери, які стають фінансистами, дозволять користувачам відфільтрувати найпопулярніших майнерів, щоб їм не довелося сліпо прив’язувати кошти до випадкових фінансистів, які не мають жодного відношення до життєздатності мережі.
**Фінансистам (майнерам) потрібно лише заблокувати свої Sats за допомогою реле Nostr, без передачі самих даних між користувачами та реле. **Фінансист (майнер) просто повинен підписати запит користувача, щоб користувач міг напряму взаємодіяти з усіма реле Nostr, до яких підключений фінансист - 4 кроки для ZKCSP+Lightning, як зазначено вище.
на завершення
Мережа Lightning Network не існувала б без консенсусного блокчейну Bitcoin Nakamoto, оскільки користувачам не було б де зберігати свої пакетні докази транзакцій поза мережею.
Подібно до того, як користувачі об’єднують усі ці транзакції Lightning Network і поміщають невеликі докази в блокчейн, ми об’єднуємо всі дані Nostr і додаємо невеликі докази в блокчейн. Подібно до того, як Lightning Network забезпечує миттєві платежі на другому рівні, Nostr може забезпечити зберігання даних на другому рівні без ризику незахищеного бічного ланцюга. **
**Він використовує той самий підхід, що й Lightning Network, із консенсусним блокчейном Nakamoto Bitcoin на першому рівні та Nostr+ZKCSP Lightning на другому рівні. **