Протокол RGB

Що таке RGB

RGB - масштабований та конфіденційний протокол розумного контракту, який застосовується до біткоїна та мережі Lightning, розроблений Асоціацією стандартів LNP/BP. Він приймає концепції приватної та спільної власності, пропонуючи повністю універсальну, безпечну форму розподіленого обчислення без потреби у блокчейні, працюючи як система розумного контракту часткового стану, яку перевіряє клієнт.

Історія розробки протоколу RGB

Історія протоколу RGB

RGB спочатку було задумано Джакомо Зукко з BHB Network у 2016 році як «система активів, що не базується на блокчейні». Того ж року Пітер Тодд представив концепції одноразових печаток та перевірки на клієнтському боці. Інспірований цими ідеями, RGB було запропоновано в 2018 році. У 2019 році ведучу роль у розробці коду RGB та фундаментального стандарту взяв на себе основний розробник Максим Орловський. Максим Орловський та Джакомо Зукко заснували Асоціацію стандартів LNP/BPhttps://www.lnp-bp.org) для реалізації RGB від концепції до застосування, з підтримкою від Fulgur Ventures, Bitfinex, Hojo Foundation, Pandora Prime та DIBA. Після великого розвитку RGB випустив свою першу стабільну версію, V0.10, у квітні 2023 року. У січні 2024 року основні розробники RGB оголосили, що версія V0.11 буде випущена рано в першій половині року.

Останні події в протоколі RGB

Нові можливості RGB V0.10 були ретельно проаналізовані в інших звітах. Хоча V0.11 ще не було офіційно випущено, ось деякі з останніх розробок від розробників та спільноти:

• Незабаром підтримка L-BTC

• Оновлення щодо взаємодії та мостів між RGB активами та рідиною активами

Однак RGB V0.11 буде несумісним з V0.10, що призведе до значних витрат на міграцію для поточних проєктів. Крім того, через повільний темп розробки багато проєктів наразі чекають на випуск V0.11.

Філософія дизайну RGB та принципи роботи

RGB смарт-контракти використовують перевірку на клієнтському боці, що означає, що всі дані зберігаються поза транзакціями Bitcoin, а саме, на блокчейні Bitcoin або стані каналів Lightning. Це дозволяє системі працювати на вершині мережі Lightning без будь-яких змін в основній мережі BTC або протоколах мережі Lightning, ложачи фундамент для масштабованості та конфіденційності протоколу.

RGB використовує одноразові печатки, визначені на Bitcoin UTXO, що надає можливість будь-кому з історією стану смарт-контракту перевірити його унікальність. Іншими словами, RGB використовує Bitcoin скрипти для реалізації своєї моделі безпеки та визначення прав власності та доступу.

RGB - це напрямлений ациклічний граф (DAG) переходів стану, де контракти повністю ізольовані один від одного, і ніхто не знає про їх існування, крім власників контрактів (або тих, кому власник розкриває інформацію про контракт).

Направлений ациклічний граф (DAG) - це спеціальна графова структура, яка може живо описати складні системи або взаємозв'язки. У DAG кожне ребро можна розглядати як односторонню вулицю в місті, яка представляє аспект "напрямленості" графа. Припустимо, в цій мережі вулиць, незалежно від того, як ви подорожуєте, неможливо повернутися до початкової точки і утворити замкнуте петлею; це відображає "ациклічну" природу графа. У DAG немає послідовності вузлів, яка дозволила б вам почати з одного вузла, подорожувати через серію ребер і повернутися до того ж вузла.

Застосовуючи цей концепт до системи RGB, кожний контракт можна розглядати як вузол у графі, а відносини між контрактами (такі як передача власності) можна розглядати як направлені ребра. Ця структура забезпечує, що відносини між контрактами є чіткими та впорядкованими, без утворення закритих петель, що означає, що контракт не може безпосередньо або опосередковано впливати на себе.

Цей дизайн забезпечує унікальність та незмінність зобов'язань у передачі стану, запобігаючи подвійне витрачання та досягаючи ефективних та послідовних переходів стану.

Занурення в контракти RGB

Після розуміння основних принципів архітектурного дизайну RGB давайте поглянемо на частину контракту. У сучасному світі смарт-контрактів творцям потрібно організовувати або виконувати розробку коду смарт-контракту самостійно. Філософія дизайну RGB вважає цю практику небажаною, що призводить до збільшення уразливостей коду контракту та кількох хакерських атак. Тому RGB має на меті зменшити ризик уразливостей у розробці та необхідність аудитів, вводячи концепцію "Схеми шаблонів". "Схеми шаблонів" — це фактичний код смарт-контрактів. Видавці можуть використовувати їх як "шаблони контрактів", не потребуючи кодування або аудитування власного коду, написаного для них якимось випадковим підрядником.

Гнучка масштабованість та хороша сумісність

RGB-контракти визначаються декларативно, а не імперативно. Це означає, що логіка контракту визначається не серією команд або кроків, а набором правил, які описують його поведінку і переходи станів, утворюючи спрямований ациклічний граф (DAG) змін стану. Ключ до локальних державних операцій лежить у схемі. Операції в RGB-контрактах локальні, а не глобальні. Кожен вузол (або стан) має свої правила і відповідає лише за свої переходи станів. Це відрізняється від глобальних алгоритмів на таких платформах, як Ethereum, які вимагають, щоб кожен штат дотримувався одного і того ж алгоритму. Ця характеристика робить RGB досить гнучким і масштабованим, а також забезпечує хорошу сумісність.

Спрощене створення смарт-контрактів

Схема визначає, які типи глобальних та власних станів, печаток та метаданих дозволені при переходах стану. RGB використовує мову Contractum для написання схем RGB та AluVM (віртуальна арифметична логічна одиниця), спрощуючи написання розумних контрактів RGB. AluVM базується на реєстровому дизайні без випадкового доступу до пам'яті, що робить його дуже підходящим для розумних контрактів, віддаленого виконання коду, розподіленого та краєвого обчислення, забезпечуючи основу для різноманітних високорівневих використань розумних контрактів.

Як RGB забезпечує безпеку та конфіденційність

Від самого дизайну RGB:

• Приватність без глобального мовлення: Як зазначено, перевірка RGB на клієнтському боці означає, що процес перевірки відбувається лише між безпосередньо зацікавленими пірами, а не всією мережею. Цей підхід неглобального транслювання підвищує приватність та стійкість до цензури, оскільки деталі стану контракту видимі лише відповідним учасникам, а шахтарі не можуть бачити деталі транзакції.

• Конфіденційність даних в середовищі пісочниці: з іншого боку, RGB зберігає всі дані операцій у кишені. Оскільки RGB не ґрунтується на блокчейні, зберігання не реплікується на інші вузли рівнозначності. Зберігання, що контролюється локально користувачами, зменшує ризик зовнішніх атак та витоків даних, гарантуючи конфіденційність даних. RGB - це обчислювальна платформа, де кожна програма («смарт-контракт») ізольована у своєму середовищі пісочниці, що пропонує кращу масштабованість та безпеку, ніж платформи, що базуються на блокчейні. Однак зовнішні дані також означають ризик втрат.

• Поза перевіркою та зберіганням, система виставлення рахунків також забезпечує безпеку та конфіденційність. Операції з контрактами в RGB виконуються шляхом створення рахунків, які можуть містити кілька запитів на операції з контрактом. Дозволяючи користувачам явно вказувати та перевіряти операції з контрактами, покращується точність та безпека операцій. У той же час система виставлення рахунків підтримує приватну передачу запитів на операції з контрактом між користувачами, підвищуючи конфіденційність транзакцій. Переходи між станами, такі як перекази токенів, виконуються за допомогою рахунків та конкретних команд.

З погляду взаємодії з BTC

Дизайн RGB сильно пов'язаний з UTXO. Під час взаємодії з основною мережею BTC користувачі створюють оффчейн контракти для випуску активів RGB та їх виділення на UTXO Bitcoin, схоже на Мережу Блискавок. Потім трансфери активів, контрактні взаємодії та валідації виконуються оффчейн, як було введено вище.

RGB користується покращеними протоколами багатоцільового підпису, підписів на основі адаптерів та контрактів з блокуванням часу точки (PTLC), які привнесли підписи Schnorr, але її переваги базуються виключно на Bitcoin (тобто непрямо). У RGB немає нічого, що потребує підписів (тому Schnorr не вносить жодних внутрішніх змін), і воно не використовує скриптів Bitcoin (тому новий Tapscript не корисний).

BTC Security Lab, спільно заснований ScaleBit, - це присвячена лабораторія з безпеки BTC, яка працює над останніми розробками протоколу RGB. Її метою є захист безпеки контрактів, спільне просування постійного зростання та зміцнення протоколу RGB та інфраструктурної будівництва екосистеми BTC.

Огляд проектів екосистеми RGB

BiHelix

• Вебсайт: https://www.bihelix.net/

• BiHelix – це інфраструктура екосистеми Bitcoin, оптимізована для вузлів, побудована на власному блокчейні Bitcoin, що включає протокол RGB та мережу Lightning Network. Він спрямований на те, щоб полегшити розробку, розширити варіанти використання Bitcoin і вирішити проблеми масштабованості та неповноти Тюрінга, з якими стикається блокчейн Bitcoin. BiHelix прагне створити більш справедливий децентралізований криптографічний світ для майнерів, валідаторів, постачальників послуг вузлів, бірж і користувачів. Як перша інфраструктура, побудована на протоколі RGB, BiHelix розробить наступне покоління великомасштабних сценаріїв застосування біткойнів. Наразі проєкт перебуває на стадії розробки та ще не відкритий для взаємодії; слідкуйте за новинами.

  Особливості проекту

• Низький поріг користувача: Використовує протокол SLR (Security-Lightning-RGB), перепаковуючи RGB та мережу Lightning із інноваційними рішеннями для вузлів Lightning з метою досягнення універсального платежу.

• Висока надійність та масштабованість: Використовує зрілу архітектуру хмарних послуг, повністю використовуючи функції rust-lightning для підтримки функцій фабрики каналів, ефективного управління каналами та масового створення каналів.

• Захист та конфіденційність: передача та зберігання даних стану поза ланцюгом за допомогою рекурсивних доказів знань серед інших технологій для рандомізації багатофакторних платежів та вибору шляху для захисту конфіденційності.

• Зручний для розробників: Надає широкий спектр інструментів для розробки, включаючи документацію з відкритим вихідним кодом, інструменти тощо, і впроваджує механізм соціальної згоди схеми, що спрощує розробку додатків для розробників.

  Iris Wallet

• Веб-сайт: https://play.google.com/store/apps/details?id=com.iriswallet.testnet&pli=1

• Гаманець IRIS, перший гаманець для Android, розроблений командою Bitfinex, присвячений інтеграції RGB та інструментам, пов'язаним з RGB, що підтримує функціональні та нефункціональні активи. Iris Wallet дозволяє здійснювати операції з активами RGB від емісії до витрат і отримання, упаковуючи всі функціональні можливості в знайомому додатку для гаманців, абстрагуючи якнайбільше технічних деталей. Зараз це експериментальний додаток, рекомендований для невеликих сум Bitcoin та активів низької вартості.

  DIBA

• Веб-сайт: https://diba.io/

• DIBA - перший ринок NFT на Bitcoin, що використовує протокол RGB та мережу Lightning. Його мета - формувати розуміння необслуговуваних художніх активів на блокчейні Bitcoin.

  Bitmask

• Веб-сайт: https://bitmask.app/

• Створений DIBA, Bitmask - перший гаманець NFT в екосистемі RGB, який працює в веб-переглядачах та взаємодіє з RGB-контрактами, схожими на MetaMask на Ethereum. Зараз він часто оновлюється та очікує випуску V0.11.

  Pandora Prime Inc

• Веб-сайт: https://pandoraprime.ch/

• Знаходячись в Долині Веріфай, Швейцарія, Pandora Prime також є засновником LNP/BP. Pandora Prime присвячений підтримці піонерства в галузі Bitcoin Finance за допомогою поєднання RGB смарт-контрактів та мережі Lightning. Вони розпочинають з програмованих активів на Bitcoin (RGBTC та CHFN), які можуть масштабувати пропускну здатність транзакцій до рівня VISA/MasterCard через мережу Lightning, надаючи можливості для легкої обміну цими активами. До їх продуктів входять MyCitadel (гаманець), RGB Explorer (браузер) та Pandora Network, серед іншого.

  MyCitadel

• Вебсайт: https://mycitadel.io/

• Бренд Pandora Prime, MyCitadel - перший GUI-гаманець, що підтримує RGB, створений розробниками RGB у 2021 році. Він пропонує персональні гаманці для робочого столу та гаманці для iOS/iPad. Мобільний гаманець може обробляти інтерфейсні RGB-активи.

  Дослідник RGB

• Веб-сайт: https://rgbex.io/

• Розроблений компанією Pandora Prime, RGB Explorer - перший браузер, що пропонує реєстрацію RGB активів та смарт-контракти. Наразі він підтримує RGB 20, RGB 21, RGB 25, відображаючи активи, такі як LNPBP, RGBTC, dCHF та RGBEX.

  Бітлайт Лабс (раніше Cosminmart)

• Веб-сайт: https://bitlightlabs.com/

• Bitlight Labs розробляє інфраструктуру на основі протоколу RGB, готується розгорнути кілька додатків на мережі Lightning, включаючи гаманець Bitlight для RGB utility та Bitswap, автоматизованого ринкового мейкера для BitcoinFi на мережі Lightning та протоколу RGB.

RGB Меми & NFT

1. PPRGB

   • X: @PepeRgb20

   • PPRGB наразі випущений на мережі Liquid та очікує на картографування до RGB після випуску RGB V0.11 (V0.11 також розробляє функції коду для взаємодії з Liquid).

2. MRGB Надпис

   • Надпис MRGB - це токен, який базується на клієнтській перевірці стану протоколу RGB та системі смарт-контрактів. Він працює на другому та третьому рівнях (офчейн) екосистеми Bitcoin та надасть відкрите вихідне кодування протоколу, що дозволить усім публічним ланцюжкам BRC20 безпосередньо використовувати цю систему. Ця інновація має значний потенціал для публічних ланцюжків BRC20, включаючи зменшення витрат газу, прискорення швидкості транзакцій та покращення загальної продуктивності. За допомогою системи MRGB публічні ланцюжки BRC20 зможуть опрацьовувати транзакції більш ефективно та зменшувати витрати на транзакції для користувачів. Тим часом, токен надпису MRGB також буде служити витратним у процесі транзакції, тим самим збільшуючи ліквідність та масштабованість BTC.

3. Одноразова печатка

   • X: @Single_Use_Seal

   • Seal - це колекція з 10 тис. PFP, рідкісних UDA та токенів на RGB20 та RGB21, названа на честь концепції одноразового печатка Пітера Тодда. Зараз чекає на оновлення гаманців Bitlight і Bitmask до версії v0.11 RGB, після чого вони будуть випущені на них.

4. Бітмен

   • X: @bitmancity

   • Випустить 10 тис. UDA на діба, можливо через wl+публічний продаж, з місією "передачі духу BTC". Проєкт має похвальну мету і надасть wl учасникам екосистеми BTC, причому більшість виручки від публічного продажу буде пожертвована на LNP/BP.

БітVM

Чому BitVM?

BitVM (Bitcoin Virtual Machine) впроваджує систему, яка дозволяє перевіряти будь-які обчислення на біткоїновій блокчейн без порушення його безпеки або зміни мережі. Цей розвиток відкриває двері для складних обчислень, таких як повністю універсальні розумні контракти, причому всі обчислення обробляються поза ланцюгом для зменшення заторів на біткоїновому блокчейні.

У простих термінах, BitVM - це обчислювальна модель, здатна виражати контракти, що підтримують повну машину Тьюрінга в мережі Bitcoin.” Як і RGB, BitVM не потребує модифікацій правил консенсусу мережі.

9 жовтня 2023 року Робін Лінус, співзасновник розробника блокчейн ZeroSync, опублікував білий папір BitVM. Порівняно з RGB, BitVM набагато молодший.

Архітектура дизайну BitVM

Архітектура

Подібно до оптимістичних роллапів та пропозиції Merkelize All The Things (MATT), заснованої на доказах шахрайства та протоколах відповіді на виклик, це не потребує змін у правилах консенсусу Bitcoin. BitVM демонструє, що Bitcoin є повністю тьюрінг-повним у кодуванні доказів шахрайства великими Taptrees.

Дизайн ворітного контуру

Зобов'язання Bit Value є найбільш базовим компонентом, що дозволяє зобов'язаному встановити значення певного біту на «0» або «1». Будь-яку обчислювальну функцію можна представити у вигляді логічного комірки, формуючи зобов'язання логічних воріт. Побудовані через ворота NAND (універсальні логічні ворота), кожне ворото має власне зобов'язання. Будь-який коло можна виразити шляхом поєднання зобов'язань воріт. Кожний крок виконання зобов'язаний в Tapleaf і комбінується у межах тієї ж самої адреси Taproot.

BitVM використовує оновлення Taproot Bitcoin, створюючи структуру, подібну до двійкової схеми (називається taptree), щоб досягти своєї функціональності. У цій системі умови витрат для кожного UTXO, представлені інструкціями у Script, утворюють основну одиницю програми. Ці інструкції генерують двійкові виходи (0 або 1) у Taproot-адресі, тим самим конструюючи весь taptree. Результат taptree може бути розглянутий як результат виконання двійкової схеми, подібно до виконуваної програми. Складність програм, які може виконати taptree, залежить від кількості та складності Taproot-адрес, які його складають. Коротко кажучи, BitVM реалізує можливість виконання більш складних програм в мережі Bitcoin, перекладаючи інструкції Script Bitcoin у двійкові операції.

Участь беруть дві сторони

На даний момент модель обмежена двома сторонами і не може бути розширена для включення більшої кількості учасників. Крім того, для правильної роботи BitVM потрібна велика кількість попередніх підписів (обчислення поза ланцюжком), що робить BitVM досить складним і потенційно неефективним.

Докази шахрайства та протокол відповіді на виклик

Як доказуючий, так і викликач вносять однакову кількість BTC у транзакцію як ставку (як вхід), а вихід цієї транзакції буде включати логічне коло. Під час фази налаштування підписуються передбачені серії транзакцій, щоб спростувати неправильні заяви. Біт ВМ порівнюється з Оптимістичними Роллапами, оскільки він виконує більшість обчислень поза ланцюжком та подає деякі з цих обчислень на ланцюжок для вирішення суперечок у випадку їх виникнення.

Оптимістичні Rollups - це рішення масштабування другого рівня, яке зменшує навантаження на базовий рівень, переміщуючи обчислення та зберігання даних поза ланцюжком. Потім вони пакують кілька транзакцій та публікують їх на головний ланцюжок. Оптимістичні Rollups припускають, що всі транзакції є валідними. Однак, якщо учасники мережі помічають нечесну поведінку, вони можуть ініціювати доказ шахрайства. Доказ шахрайства - це доказ невірних обчислень когось. Вони створюються після перевірки.

Позаланцюжкове обчислення

Майже всі дії на БітVM відбуваються поза ланцюжком блоків. Це включає в себе ініціювання обчислювальних завдань, обмін даними та перевірку поданих претензій. БітVM, як правило, не виконує обчислень на ланцюжку блоків Bitcoin. Обчислення та перевірки публікуються на ланцюжку блоків лише в разі суперечки через підозру у шахрайстві. Однак, якщо виникає суперечка, невелика частина процесу розгляду суперечки дійсно відбувається на ланцюжку блоків, достатньо для визначення того, яка сторона недобросовісна.

З вищезазначеними базовими знаннями ми можемо краще зрозуміти конкретні принципи взаємодії двох сторін BitVM.

Модель взаємодії двох сторін BitVM включає довідника та перевірника. У цій системі довідник спочатку створює та подає смарт-контракт або програму, а потім надсилає кошти на спільно контрольовану основну адресу майстра. Ці кошти зберігаються в угоді мультипідпису 2 з 2. Довідник також повинен надати перевірнику достатньо інформації для доведення того, що їх програма може виробити обіцяний вихід.

Завдання верифікатора - виконати код перевірника та перевірити, чи відповідає вихід вимогам. Якщо вихід не відповідає, верифікатор викличе перевірника. Цей процес взаємодії виклик-відповідь передбачає обмін даними поза ланцюжком та використання попередньо підписаних транзакцій для перевірки правильності обчислення.

Якщо виявлено обчислювальну помилку, верифікатор може публічно довести нечесну поведінку доказувальника за допомогою доказового шахрайства на ланцюжку. У системі BitVM, якщо відповідь доказувальника виявиться неправильною, вони втратять ставку і втратять кошти. Навпаки, якщо всі відповіді вірні, доказувальник залишить свої кошти. Цей економічний стимулюючий механізм розроблений для запобігання нечесної поведінці.

У кінцевому підсумку ця взаємодія гарантує, що обчислювальна перевірка передається тільки на блокчейн Bitcoin у разі спору, тим самим виконуючи велику частину обчислень поза ланцюжком. Ця конструкція забезпечує ефективність мережі Bitcoin, дозволяючи при цьому виконувати більш складні програми на Bitcoin.

Безпека BitVM

З точки зору архітектурного проектування безпека БітVM ґрунтується переважно на наступних аспектах:

Докази шахрайства

У разі суперечки валідатори можуть викликати неправильні заяви пропонента через докази шахрайства. Цей механізм схожий на Оптимістичні Роллапи і не потребує зміни правил консенсусу Bitcoin.

Протокол виклик-відповідь

BitVM використовує протокол виклик-відповідь, де пропоненти та валідатори підписують серію транзакцій заздалегідь під час фази налаштування протоколу. Ці транзакції використовуються для вирішення питань, коли виникає суперечка.

Обчислення поза ланцюжком з верифікацією на ланцюжку

BitVM дозволяє виконувати складні обчислення поза ланцюжком, тоді як перевірка та вирішення відбуваються лише на ланцюжку у разі спору. Цей підхід зменшує споживання ресурсів на ланцюжку, зберігаючи цілісність та безпеку блокчейну Bitcoin.

Механізм депозиту та штрафів

Якщо пропонент робить невірне заявлення, валідатори можуть конфісковувати їх депозит. Цей механізм гарантує, що атакувальники завжди втрачають свій депозит за неправомірні дії.

Механізм двостороннього контракту

Цей механізм забезпечує кращу конфіденційність на БітVM та зменшує витрати на транзакції, але порівняно з багатостороннім механізмом EVM, його універсальність трохи зменшується.

Протокол Nostr

Що таке Протокол Nostr

Nostr означає «Примітки та інші речі, передані ретрансляторами», вказуючи на те, що це протокол передачі, що включає ретранслятори, що свідчить про те, що це не протокол передачі від ровер до ровера (P2P). Згідно з Код GitHubоновлювати записи, цей проект був запущений у листопаді 2020 року. Протокол має на меті створення найпростішого відкритого протоколу для цензуростійкої глобальної соціальної мережі. Це децентралізований соціальний протокол, який дозволяє користувачам створювати, публікувати та підписуватися на будь-який тип контенту без контролю або втручання з боку будь-яких централізованих платформ або установ. Nostr бере натхнення з Bitcoin та мережі Lightning, використовуючи схожі криптографічні та консенсусні механізми, а також структуру даних на основі подій, відому як мережа Nostr.

Компоненти протоколу Nostr

Публічний та Приватний Ключові Пари

Пара публічного та приватного ключів становить обліковий запис Nostr. На відміну від традиційної системи імен користувачів та паролів, облікові записи Nostr використовують систему публічних та приватних ключів, схожу на криптовалюти. Для спрощення публічний ключ можна сприймати як ім'я користувача, а приватний ключ – як пароль. Важливо зауважити, що коли втрачений приватний ключ, його не можна скинути, як пароль. Публічні ключі починаються з npub1, а приватні – з nsec1. Важливо забезпечити безпечне зберігання цих ключів, оскільки їх неможливо відновити, якщо втрачені.

Клієнт

Nostr - це протокол для відправки інформації через Інтернет, для використання якого потрібне клієнтське програмне забезпечення. Клієнти можуть бути веб-сторінками, настільними програмами або мобільними додатками. Клієнти читають інформацію з реле та відправляють новостворені дані на реле для зчитування іншими клієнтами. Інформація включає підписи для забезпечення того, що дані надсилається автентичним відправником. Клієнт використовує приватний ключ для створення підписів. При використанні настільного або мобільного клієнта вперше, приватний ключ потрібно зберегти в ньому. Публічний ключ можна отримати з приватного ключа. Для веб-клієнтів не рекомендується безпосередньо зберігати приватний ключ в них; краще використовувати плагін для збереження приватного ключа.

Реле

Під ретрансляторами можна розуміти внутрішні сервери протоколу Nostr. Клієнти Nostr відправляють інформацію в ретранслятори, які можуть (або не можуть) зберігати інформацію і транслювати її всім підключеним клієнтам. Важливо зазначити, що реле не є постійними; З часом вони можуть істотно змінюватися. Протокол Nostr покладається на реле для зберігання та отримання даних. Якщо користувач відчуває низьку швидкість клієнта, це може бути пов'язано з низькою швидкістю підключеного реле, і він може розглянути можливість додавання інших реле.

NIPs

NIPs (Nostr Implementation Possibilities) - це стандарти, які використовуються для регулювання Nostr-сумісних реле та клієнтського програмного забезпечення, що вказує, що слід, може або може бути реалізовано. "NIP" відноситься до посилань на документи, які визначають, як працює протокол Nostr. Nostr є децентралізованим протоколом, який не монополізується якою-небудь централізованою сутністю (наприклад, Twitter), що означає, що його напрямок розвитку залежить від усіх учасників. Ми можемо пропонувати та підтримувати зміни, а також надавати відгуки на інші ідеї. Як активні учасники спільноти протоколу, кожен має певне слово у майбутньому напрямку розвитку мережі Nostr. NIPs у основній кодовій базі були затверджені, і нові ідеї можуть бути додані через запити на відтягування.

Ключові NIP включають:

• NIP-04: Шифрування повідомлень за допомогою алгоритму secp256k1 для обміну ключами Діффі-Хеллмана, що дозволяє шифрування від кінця до кінця.

• NIP-05: Відображення публічних ключів на доменні імена для легкого запам'ятовування, наприклад, відображення публічного ключа автора на@NomandJamesдомен.

• NIP-06: Мнемонічні фрази, подібні до тих, що використовуються в гаманцях криптовалют.

• NIP-13: Доказ роботи. Цей концепт попереджає Bitcoin і широко використовується в шарах консенсусу POW блокчейну та протоколі шепоту Ethereum. Це включає завершення обчислювально інтенсивного доказу роботи перед відправленням повідомлення, яке перевіряє приймаючий ретрансляційний сервер. Надання цього доказу означає витрачання обчислювальної потужності, підвищуючи поріг для спаму ретрансляційні сервери з непотрібними повідомленнями.

• NIP-22: Відмітки часу повідомлень. Повідомлення реле про час створення повідомлення, що дозволяє реле вибірково приймати повідомлення. Часові позначки можна встановлювати на минуле або майбутнє.

• NIP-40: Термін придатності. Інформування серверів ретрансляції про закінчення терміну дії повідомлення, щоб його можна було видалити.

• NIP-57: Спрямовані посилання на мережу Lightning Network.

• NIP-65: Рекомендований список ретрансляційних служб.

Події - єдине Об'єктструктуру на Nostr. Кожна подія має добрийвказати тип події (яку дію користувач виконав або яку інформацію він отримав).

Операція протоколу Nostr

Протокол Nostr працює через реле. Ці ретранслятори дозволяють користувачам одного ретранслятора надсилати файли JSON один одному.

Щоб краще зрозуміти це, розгляньте спрощену схему:

Діаграма включає 3 реле та 3 клієнти, кожен клієнт використовує різні платформи.

На цій схемі:

• Боб може бачити всі твіти Еліс, але жодного з Мері (Боб навіть не знає про існування Мері).

• Аліса може бачити всі твіти Боба, але жодного твіта Мері (Аліса також не знає про існування Мері).

• Мері може бачити твіти як від Боба, так і від Аліси, оскільки вона записує дані лише на Реле 3, але може читати дані з Реле 2 (де зберігаються дані Боба та Аліси).

Глибоке вивчення контрактів Nostr

Оскільки Nostr протокол є дуже легким відкритим протоколом, він надає набір специфікацій протоколу для децентралізованих платформ соціальних мереж. Давайте проведемо простий аналіз коду протоколу:

Основою протоколу є сервер WebSocket (відомий як nostr-relay), який обробляє та зберігає дуже просту структуру даних, яку називають Подія. Це показано наступним чином:

{  "id": "<32-байтовий sha256 серіалізованих даних події>",  "pubkey": "<32-байтовий шістнадцятковий публічний ключ творця події>",  "created_at": "<часовий знак unix у секундах>",  "kind": "<ціле число>",  "tags": [    ["e", "<32-байтовий шістнадцятковий ідентифікатор іншої події>", "<рекомендований URL ретрансляції>"],    ["p", "<32-байтовий шістнадцятковий ключ>", "<рекомендований URL ретрансляції>"],    ... // інші види тегів можуть бути включені пізніше  ],  "content": "<довільний рядок>",  "sig": "<64-байтовий підпис хешу sha256 серіалізованих даних події, який збігається з полем 'id'"}

Події завжди підписані (з використанням підписів типу Schnorr) і містять структуровані дані, які можуть мати різні семантичні значення. Тип Schnorr XOnlyPubkeys, визначений в BIP340 (наразі використовується з Bitcoin Taproot), використовується як "ідентичності" протягом усього протоколу.

Клієнт програми nostr - це програма, яка може спілкуватися з nostr-relay і використовувати абонентів для підписки на будь-який набір подій.

Фільтри представляють собою набір всіх подій Nostr, які цікавлять клієнта.

Клієнти не повинні реєструватися або створювати облікові записи, оскільки клієнт використовує публічний ключ користувача для ідентифікації. Кожного разу, коли клієнт підключається до реле, він надсилає фільтр підписки користувача, і поки вони підключені, реле буде транслювати "події цікавості" клієнту.

Реле можуть кешувати підписки клієнтів, але це не обов'язково. Клієнти повинні вирішувати все на «стороні клієнта», тоді як реле можуть бути такими ж глупими, як камінь.

Клієнти не спілкуються між собою. Але Реле можуть. Це дозволяє реле отримувати дані для клієнта, яких у нього немає, і клієнти можуть підписатися на події поза реле, до якого вони підключені.

На перший погляд це створює враження, що Nostr як протокол є безглуздим (чому б не просто підписати та викинути вихідний JSON і дозволити клієнту розібратися?), але більш глибоке дослідження показує, що модель "тупий сервер, розумний клієнт" може виявити деякі значні переваги в інженерії децентралізованого дизайну протоколу.

Повністю децентралізований як ключова функція Nostr

Nostr виступає як протокольний шар для соціальних додатків, передаючи нотатки та інші речі через ретранслятори без покладання на будь-які централізовані сервери. Його повна децентралізація дозволяє будь-якому додатку вільно отримувати доступ через розподілену мережу, забезпечуючи відкриту та бездозвільну соціальну платформу. Таким чином, Nostr не пропонує прямий продукт для споживачів, але фокусується на впровадженні необхідної соціальної інфраструктури на рівні протоколу. Можливість продуктизації забезпечується сторонніми додатками, а користувачі різних додатків можуть взаємодіяти соціально один з одним.

Перевага Nostr полягає в тому, що він надає дійсно вільну і відкриту соціальну мережу, на яку не впливає і не загрожує ніяка централізована влада або інтереси. Користувачі можуть вільно висловлювати свої думки та переконання, не побоюючись цензури, заборон чи деплатформи; Творці контенту можуть вільно встановлювати свої моделі заохочення, не турбуючись про те, що їх позбавлять доходу або зіткнуться з недобросовісною конкуренцією. Користувачі Nostr також можуть вільно обирати своє коло спілкування, не побоюючись маніпуляцій, дезінформації чи порушення конфіденційності.

Nostr значно відрізняється від традиційних соціальних мереж та має наступні особливості та переваги:

Децентралізація: Nostr не покладається на жодні централізовані сервери або платформи, а замість цього використовує мережу Bitcoin для передачі та зберігання інформації. Це забезпечує, що користувачам не потрібно турбуватися про крадіжку даних, цензуру або видалення, і вони не підпадають під правила або політику будь-яких третіх сторін.

Самовлада: Nostr дозволяє користувачам контролювати свої власні дані та ідентичність. Користувачі можуть вільно вибирати, кого вони хочуть слідувати та кому довіряти, висловлювати свої погляди та ідеї без страху бути заблокованими, забороненими або пониженими, і без страждання від рекламних повідомлень чи втручання рекомендованого вмісту. Перевірка певних користувачів також полегшує виявлення спаму та вмісту, створеного ботами.

Відкритість : Nostr - це відкритий протокол, в якому будь-хто може брати участь і робити свій внесок. Користувачі можуть розробляти та використовувати різні клієнти, а також створювати та запускати власні ноди (сервери, які можуть пересилати та зберігати інформацію Nostr). Користувачі також можуть створювати та використовувати різні типи та теги, які є метаданими, що використовуються для диференціації та категоризації інформації Nostr. Простий і гнучкий Подіяформат підтримує різноманітні типи публікацій: дописи в соціальних мережах, довідковий контент, багатомедійний контент, електронна комерція тощо. Крім того, інтеграція Nostr з мережею Lightning сприяла новій моделі бізнесу на основі вартості-за-вартість, справедливішій.

Питання безпеки протоколу Nostr

Управління приватним ключем

Протокол Nostr використовує пари ключів публічного та приватного для облікових записів, що вимагає від користувачів належного управління їхніми приватними ключами. Якщо втрачено, приватний ключ не може бути відновлений. Це може становити виклик для більшості користувачів, які можуть не мати технічних знань та досвіду для безпечного управління приватними ключами.

Вибір реле

У протоколі Nostr користувачі повинні обрати та перевірити реле самостійно. Вибір ненадійного або зловісного реле може призвести до витоку, підроблення або видалення їх інформації.

Розповсюдження інформації

У протоколі Nostr інформація, надіслана користувачами, не поширюється через кілька ретрансляторів. Це означає, що якщо їхню інформацію не отримано та не збережено достатньою кількістю ретрансляторів, вона може бути втрачена або не побачена іншими користувачами, ускладнюючи проблему інформаційних силосів.

Зберігання відомостей на власний розсуд ретрансляторів

Реле в протоколі Nostr вільно вирішують, чи отримувати та зберігати інформацію користувачів. Це може призвести до того, що деякі реле виберуть отримувати та зберігати лише ту інформацію, яку вони вважають цінною або яка відповідає їхнім інтересам, ігноруючи або відхиляючи іншу інформацію.

Розширення шкідливих протоколів

Хоча протокол Nostr визначає деякі основні типи подій і функціональні можливості, він також дозволяє клієнтам і ретрансляторам вибірково впроваджувати додаткові функції. Це може призвести до впровадження небезпечних або шкідливих функцій деякими клієнтами та ретрансляторами, що вплине на безпеку та конфіденційність користувачів.

Обробка інформації

Через відсутність шару консенсусу в протоколі Nostr, деякі реле не обробляють повідомлення з важливою різницею в часових мітках та часі UNIX, що залишає можливість клієнтам використовувати цю розбіжність для підробки повідомлень.

Огляд екосистеми Nostr

Джек Дорсі, співзасновник Twitter та великий прихильник протоколу Nostr, пожертвував 14,17 біткоїнів (приблизно 245 000 доларів) на підтримку його розвитку в грудні 2022 року. Його профіль X відображає його особисту адресу Nostr, що свідчить про його прихильність до протоколу.

Damus⚡️: Основні застосування протоколу Nostr

X：https://twitter.com/damusapp

Damus - це соціальний додаток, який підтримує підказки Bitcoin через мережу Lightning, замінюючи звичайний «Подобається» або пальцем угору з підказкою. Низькі комісії за транзакції мережі Lightning роблять підказки практично безкоштовними. Окрім Damus, застосунки протоколу Nostr включають комунікаційний інструмент Anigma, засіб для обміну текстами Sendtr та онлайн-гру в шахи Jeste, серед інших.

Основний медіа-партнер протоколу Nostr: TGFB

TGFB - це християнська платформа для навчання Bitcoin, спрямована на навчання і підготовку християн зрозуміти Bitcoin і використовувати його для прославлення Бога та користі людства. Значна частина її контенту присвячена просуванню протоколу Nostr через подкасти, які ведуть Джон та Джордан, досліджуючи наслідки протоколу з християнської перспективи. Поєднання християнства, відомого в США та всесвітньо, схваленого SEC Bitcoin ETF та протоколу Nostr, побудованого на великій користувацькій базі мережі Lightning, очікується, що значно сприятиме прийняттю та підтримці протоколу Nostr.

Протоколи похідних Nostr

Активи Nostr + Taproot

Протокол активів Nostr - це відкритий протокол, який інтегрує активи Taproot та платежі нативного Bitcoin (виражені в сатоші) в екосистему Nostr, підтримуючи взаємодію з іншими платіжними протоколами, включаючи Мережу Lightning та активи Taproot.

Після введення активів вони можуть бути відправлені та отримані за допомогою публічних та приватних ключів протоколу Nostr, при цьому врегулювання та безпека все ще ґрунтуються на мережі Lightning. Протокол активів Nostr, хоча й побудований на технології Nostr, є відмінним протоколом, який сприяє основним транзакційним функціям через повідомлення Nostr.

Повний кастодіальний сервіс Протоколу активів Nostr передбачає, що користувачі вносять свій Bitcoin або інші активи на гаманець, керований протоколом, а потім виконують інструкції з розгортання токенів, чеканки та передачі через повідомлення Nostr.

Проте повна кастодіальна служба є контроверсійною через потенційні ризики безпеки. Користувачі не можуть повністю контролювати свої активи, і в разі порушення платформи або виходу з гришми вони можуть втратити всі свої активи.

Крім того, після запуску 30 жовтня Nostr виявив високий попит на депозити активів, що призвело до частої технічної підтримки та вимкнення сайту, що викликало певні занепокоєння щодо досвіду команди та надійності проекту. 8 листопада протокол активів Nostr офіційно відповів на коментар на китайській мові у твіті, проте деякі користувачі все ще питаються про достовірність проекту. Спільнота Nostr висловила сильний протест проти токена, пов'язаного з цим протоколом розширення.

Nostr + Надпис

Noscription - це експериментальний токен-протокол, заснований на Nostr, який дозволяє користувачам створювати та торгувати токенами, схожими на brc-20, відмінними від токенів активів Taproot.

Порівняльний аналіз

Реалізація протоколу

• БітVM вимагає надзвичайно високої обчислювальної потужності і наразі існує тільки в теорії. З погляду комерційної реалізації, RGB має значну перевагу з великою кількістю вже використовуваних застосувань. (Технічна організація за RGB, LNP/BP, має кількох розробників і є неприбутковою, що призводить до повільного прогресу розвитку). Nostr, утруднений загальними перешкодами SocialFi, також не зміг сприяти подальшому розвитку екосистеми застосування свого протоколу.

  Захист конфіденційності

• Як RGB, так і BitVM виконують обчислення поза ланцюжком, але протокол RGB гарантує, що сторонні особи не можуть відстежувати історію активів RGB на блокчейні. Лише коли користувач отримує актив, він дізнається його історію, функція, недосяжна для BitVM. Протокол Nostr, який є соціальним протоколом, має великий ступінь невизначеності у передачі інформації, що потенційно може призвести до витоку інформації, блокування, втрат та зловживань через вразливості.

  Нативна сумісність з BTC

• Як RGB, так і BitVM не потребують змін у протоколі Bitcoin; Nostr побудований на власній мережі Lightning, пропонуючи відносно хорошу внутрішню сумісність та безперешкодний досвід розробки.

  Протокол безпеки

• Протокол RGB працює поза ланцюжком в пісочниці, забезпечуючи безпеку даних. Його система виставлення рахунків також гарантує безпеку даних з точки зору дизайну. Щодо взаємодії з BTC, він використовує механізм, схожий на мережу Lightning для випуску активів.

• BitVM використовує модель Rollup, виконуючи дані поза мережею. Характеристики віртуальної машини в поєднанні з доказами шахрайства та моделлю виклик-відповідь забезпечують безпеку BitVM.

• Nostr використовує ретрансляційну модель, де геніальна конструкція передачі інформації між ретрансляторами та алгоритми шифрування забезпечує безпеку інформації в протоколі Nostr.

У галузі Web3 досі не існувало лабораторії, спеціалізованої саме на безпеці екосистеми Bitcoin, доки не було засновано BTC Security Lab, яке заповнює цей прогалину, надаючи професійну підтримку безпеки та дослідження для екосистеми Bitcoin. ScaleBit та BiHelix мають на меті очолити гонку в галузі безпеки екосистеми Bitcoin, встановлюючи стандарти безпеки для галузі та сприяючи здоровому розвитку екосистеми.

Екосистема та Комерціалізація

• Як соціальний протокол, Nostr перевершує як BitVM, так і RGB за кількістю користувачів та популярністю трафіку, що робить його екосистему протоколу розвитку та комерціалізації додатків більш комплексними, ніж у двох інших.

• Протокол RGB існує вже деякий час, і наразі багато проектів очікують випуску RGB V0.11.

• БітVM випустив свій білий папір лише кілька місяців тому, і його екосистема все ще знаходиться в розробці.

Майбутнє цих трьох протоколів передбачається породити численні Dapps у галузях SocialFi, GameFi та DeFi, принесуть нову хвилю популярності в екосистему BTC.

Особлива подяка Ausdin.eth, 0xLayman, Echo, Венера за їхні внески до цього звіту.

Відмова від відповідальності：

1. Ця стаття перепечатана з[chaincatcher]. Усі авторські права належать оригінальному автору [Ланцюг Зецзянського університету, BiHelix, ScaleBit & Лабораторія безпеки BTC]. Якщо є заперечення проти цього передруку, будь ласка, зв'яжіться з Ворота Навчаннякоманда, і вони оперативно вирішать це.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодної інвестиційної ради.
3. Переклади статей на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.