Це редакція думки Шинобі, викладача-самоучки в біткойн-просторі та ведучого біткойн-подкастів, орієнтованого на технології.
Я пропоную, перш ніж читати це, прочитати У попередній статті я пояснював, що таке Nostr і як він працює на високому рівні. Тоді ви повинні мати гарне уявлення про основну структуру системи на цьому етапі, тож тепер давайте подивимося на ймовірні проблеми, які виникнуть у міру її впровадження. З платформою став популярним для біткойн-спільноти, про ці проблеми слід знати.
Як я обговорював у попередній статті, пари відкритих/приватних ключів користувача є невід’ємною частиною того, як Nostr працює як протокол. Немає імен користувачів або будь-яких типів ідентифікаторів, якими керує сервер ретрансляції, які можна пов’язувати з окремими користувачами. Це просто ті ключі користувачів, які повністю під їхнім контролем.
Це функціонує як жорсткий зв’язок між фактичним користувачем і тим, як його ідентифікують інші, що запобігає будь-якому ретрансляційному серверу роз’єднати ці дві речі, тобто надати чийсь ідентифікатор іншому користувачеві. Це вирішує одну з найбільших фундаментальних проблем платформ, які використовуються для спілкування між людьми: відсутність контролю над власними ідентифікаційними даними користувачів. Але це також представляє всі проблеми керування ключами, з якими стикається той, хто володіє закритим ключем. Ключі можуть бути втрачені, а ключі можуть бути скомпрометовані, і якщо така подія трапиться, користувачам не буде до кого звернутися за допомогою, як і з біткойнами. Немає підтримки клієнтів, щоб щось відновити. Ви втрачаєте це, ось і все.
Це неминуче викличе необхідність у схемі для користувачів, щоб змінювати одну пару ключів на іншу таким чином, щоб інші користувачі, з якими вони взаємодіють через протокол, могли бути перевірені та виявлені. Весь протокол базується на доказі того, що подія надійшла від конкретного користувача (ключ ідентифікації), тому всі ці гарантії зникають, коли чиїсь ключі зламано.
Як ти з цим справляєшся? Просто перевірте їхній обліковий запис у Twitter? Ну, тоді це не дуже децентралізована система, зрештою, якщо вам потрібно використовувати централізовану платформу, де вони не контролюють свою особу, щоб підтвердити свою особу Nostr.
Чи підтвердили інші користувачі легітимність нового ключа? Це не стосується таких ситуацій, як масовий злом ключів або незнання когось із близьких настільки добре, щоб довіряти їх атестації.
Nostr потребує справжньої криптографічної схеми, яка пов’язує обертання одного ключа з іншим. Є пропозиція від забудовника fiatjaf для базової схеми, яка потенційно може вирішити цю проблему. Основна ідея полягала б у тому, щоб взяти довгий набір адрес, отриманих з одного головного початкового числа, і створити набір «налаштованих» ключів, подібних до того, як дерева Taproot прикріплюються до ключа Bitcoin. Taproot бере корінь дерева Merkle дерева Taproot і «додає» його до відкритого ключа, щоб створити новий відкритий ключ. Це можна відтворити, додавши корінь дерева Merkle до закритого ключа, щоб отримати відповідний закритий ключ для нового відкритого ключа. Ідея Fiatjaf полягає в тому, щоб зв’язати зобов’язання в зворотному порядку від кінця до початку, щоб кожен налаштований ключ фактично містив доказ того, що для його створення використовувався наступний налаштований ключ.
Отже, уявіть, що починається з ключа Z, останнього в ланцюжку. Ви можете налаштувати це за допомогою чогось, а потім повернутися назад і створити налаштовану версію ключа Y за допомогою налаштованого ключа Z (Z' + Y = Y'). Звідси ви візьмете Y', а потім використаєте його для налаштування X (Y' + X = X'). Ви повинні зробити це аж до клавіші A, щоб отримати A', і звідти почати використовувати цю клавішу. Коли його зламано, користувач може транслювати подію, що містить неналаштований ключ A і налаштований ключ B'. Це містило б усі дані, необхідні для того, щоб показати, що B' використовувався для створення A', і користувачі могли б негайно припинити стежити за A' і натомість слідкувати за B'. Вони б точно знали, що B' є наступним ключем цього користувача, і натомість слідували б цьому.
Однак ця пропозиція все ще має деякі проблеми. По-перше, вам потрібно завчасно згенерувати всі ключі, які ви коли-небудь використовували, і він не матиме можливості обертатися до абсолютно нового набору ключів. Цю проблему можна вирішити шляхом використання головного ключа в цій схемі, який міг би нотаріально засвідчити такі ротації, або просто генеруючи дуже великий набір ключів із самого початку. Будь-який шлях буде дійсним курсом, але в кінцевому підсумку вимагатиме збереження кореневого ключа або матеріалу ключа та надання клієнтам Nostr лише окремих гарячих клавіш.
Ця схема, однак, не робить нічого для захисту користувачів або пропонує механізм для відновлення ідентичності у випадку, якщо матеріал кореневого ключа втрачено або сам скомпрометований. Це не означає, що схема fiatjaf не приносить користі, вона абсолютно є, але важливо підкреслити, що жодне рішення не вирішує кожну проблему.
Щоб трохи розповісти про потенційні рішення тут, уявіть замість ланцюжка налаштованих ключів, як він пропонує, що ключ налаштований головним холодним ключем, який також потрібно використовувати для підпису події, що обертається від одного ключа до іншого. У вас є ключ A', який отримано шляхом додавання A і M (головний ключ), а подія обертання буде A, M і B' (генерується шляхом додавання B і M) із підписом від M. M може бути пороговий ключ multisig — два з трьох, три з п’яти тощо. Це потенційно може додати надлишковість від втрати, а також забезпечити безпечний механізм для ротації ключів. Це також відкриває двері для використання служб для допомоги у відновленні або розповсюдження деяких із цих ключів серед довірених друзів. Він пропонує таку саму гнучкість, як multisig із самим біткойном.
PIN26 це також пропозиція, яка може бути дуже корисною для вирішення цієї проблеми. Це визначає розширення протоколу для подій, що дозволяє підписом одного ключа дозволяти іншому ключу публікувати події від його імені. Тоді «токен» або підтвердження делегування буде включено до всіх подій, опублікованих другим відкритим ключем від імені першого. Він навіть може бути обмежений у часі, щоб маркери делегування автоматично закінчувалися та їх потрібно було оновити.
Зрештою, як би не було вирішено, цю проблему має для Nostr у довгостроковій перспективі. Протокол, повністю заснований на парах відкритих/приватних ключів, які використовуються як ідентифікаційні дані, не може отримати популярність і прийняти, якщо цілісність цих ідентифікаційних даних не може бути захищена та підтримувана для користувачів. Зрештою це зведеться до необхідності постійного використання зовнішніх і централізованих платформ для перевірки нових ключів і координації людей, які слідкують за вашою новою ідентичністю, коли щось втрачено або зламано, і в цей момент ці інші платформи стають засобом для сіяння плутанини. і займатися цензурою.
Питання керування ключами та безпеки є серйозними проблемами з дуже великим простором дизайну, повним компромісів і проблемних точок, але це проблеми, які потрібно буде вирішити в контексті Nostr, щоб він працював. У моїй наступній статті я підсумую деякі проблеми, які, як я бачу, пов’язані з архітектурою сервера ретрансляції та проблемами масштабування, з якими розробникам Nostr доведеться зіткнутися, враховуючи основні структури даних, на яких побудовано Nostr.
Для тих, хто читає та цікавиться, чому я не згадав про децентралізовані ідентифікатори (DID): Так, це потенційне вирішення цих проблем, яке, на мій погляд, є досить комплексним. Однак розробники Nostr, здається, дуже вагаються щодо інтеграції DID у протокол або клієнти через те, що це створить зовнішні залежності за межами протоколу Nostr. Якщо ви не знайомі з тим, як DIDs працюють на технічному рівні, і вам цікаво, цю статтю за рівнем 39 є дуже добре написаним підсумком того, як вони працюють.
Це гостьовий пост від Shinobi. Висловлені думки повністю належать їм і не обов’язково збігаються з думками BTC Inc або Bitcoin Magazine.
- Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
- Платоблокчейн. Web3 Metaverse Intelligence. Розширені знання. Доступ тут.
- джерело: https://bitcoinmagazine.com/technical/solving-nostr-key-management-issues
- 7
- a
- абсолютно
- рахунки
- насправді
- адреса
- адреси
- Додає
- Прийняття
- проти
- попереду
- Aid
- ВСІ
- Дозволити
- та
- Інший
- будь
- архітектура
- навколо
- стаття
- Допомога
- Юрист
- авторизувати
- автоматично
- назад
- заснований
- основний
- ставати
- стає
- перед тим
- початок
- буття
- користь
- між
- Великий
- найбільший
- обов'язковий
- Біт
- Біткойн
- Журнал Bitcoin
- віщати
- БТД
- BTC Inc.
- побудований
- не може
- цензура
- централізована
- ланцюг
- перевірка
- клієнтів
- близько
- вчинено
- здійснення
- Комунікація
- повністю
- всеосяжний
- Компрометація
- замішання
- постійно
- контекст
- контроль
- координувати
- Core
- може
- Курс
- створювати
- криптографічні
- клієнт
- підтримка клієнтів
- дані
- Децентралізований
- Отриманий
- дизайн
- Розробник
- розробників
- обговорювалися
- Двері
- вниз
- кожен
- Редакційний
- або
- займатися
- досить
- Весь
- повністю
- і т.д.
- Навіть
- Event
- Події
- врешті-решт
- НІКОЛИ
- пояснюючи
- виражений
- розширення
- зовнішній
- знайомий
- Fiatjaf
- Перший
- Гнучкість
- стежити
- після
- друзі
- від
- Повний
- Функції
- фундаментальний
- Отримувати
- породжувати
- генерується
- породжує
- отримати
- даний
- дає
- Go
- буде
- добре
- Зростає
- гарантії
- гість
- Guest Post
- обробляти
- Обробка
- має
- тут
- Гесидант
- Високий
- господар
- Як
- Однак
- HTTPS
- ідея
- ідентифікований
- ідентифікатор
- тотожності
- Особистість
- негайно
- важливо
- in
- включені
- індивідуальний
- неминуче
- замість
- інтегральний
- інтегрувати
- цілісність
- взаємодіяти
- зацікавлений
- Вводить
- питання
- питання
- IT
- сам
- зберігання
- ключ
- ключі
- Знати
- Знання
- відсутність
- великий
- останній
- легітимність
- рівень
- Ймовірно
- обмеженою
- Довго
- подивитися
- втрачати
- від
- журнал
- зробити
- управління
- Маса
- майстер
- узгодження
- матеріал
- засоби
- механізм
- згаданий
- Мультисиг
- обов'язково
- потреби
- Нові
- наступний
- наш
- пропонувати
- Пропозиції
- ONE
- Відкриється
- Думка
- Думки
- порядок
- Інше
- інші
- поза
- власний
- Біль
- пар
- шлях
- Люди
- платформа
- Платформи
- plato
- Інформація про дані Платона
- PlatoData
- Подкаст
- точка
- точок
- популярний
- пошта
- розміщені
- потенціал
- потенційно
- попередній
- приватний
- Private Key
- Проблема
- проблеми
- доказ
- пропозиція
- пропонує
- захист
- захищений
- протокол
- забезпечувати
- громадськість
- публічний ключ
- Читати
- читання
- Відновлювати
- відновлення
- відображати
- що стосується
- оновлено
- тиражувати
- вимагати
- повертати
- корінь
- сейф
- то ж
- Масштабування
- схема
- другий
- безпечний
- безпеку
- насіння
- Послуги
- комплект
- Повинен
- Показувати
- підпис
- аналогічний
- просто
- один
- ситуацій
- So
- рішення
- Рішення
- ВИРІШИТИ
- Вирішує
- деякі
- Хтось
- що в сім'ї щось
- Простір
- конкретний
- Поширення
- Починаючи
- Як і раніше
- Стоп
- такі
- підсумовувати
- підтримка
- система
- Приймати
- приймає
- корінь
- технічний
- Команда
- їх
- речі
- три
- поріг
- через
- час
- до
- знак
- Жетони
- тяги
- торгувати
- Дерева
- Довіряйте
- Довірений
- Зрештою
- при
- використання
- користувач
- користувачі
- перевірити
- версія
- Що
- який
- волі
- в
- цікаво
- Work
- працює
- б
- письмовий
- X
- Ти
- вашу
- YouTube
- зефірнет