Багато людей починають звертати увагу на RGB-протокол Bitcoin та дійсно в захваті. Однак більшість людей досить незнайома з таким протоколом (особливо з технічно складним протоколом) і не знають, як досліджувати та спробувати вміст та екологію протоколу.
Отже, я спеціально пишу постійно оновлюваний дзеркало, щоб узагальнити відповідні навчальні матеріали та забезпечити відносно раціональний шлях навчання; в той же час воно також служить як запис особистого навчання про RGB.
Частина перша: Популярна наука Частина-початкове розуміння RGB
Коли багато людей бачать три слова RGB, вони думають про "три основні кольори: червоний, зелений, синій". Якщо ви подивитеся на піктограму, це дійсно так. Це тому, що протокол RGB використовує ранню концепцію "фарбованих монет".
Тут ми говоримо про RGB - це угода, дуже приватна, масштабована система протоколу розумного контракту, яка може працювати в мережі Bitcoin, мережі Lightning або подібних мережах.
Даний протокол наразі підтримується та оновлюється протоколом LNP/BP, а також біржа Gate бере участь у деяких роботах з кодом.
Важко просто класифікувати RGB в категорію Bitcoin L2. У нього немає власного ланцюжка, він не має власного шару, і може функціонувати на інших L2s BTC. Тому, щоб бути точними: Це універсальна технологія.
У галузі загалом вважають, що RGB та Bitvm стануть кінцевою формою розширення BTC, оскільки вони обидва можуть досягти масштабованості екосистеми BTC на основі внутрішньої природи BTC. Порівняно з Bitvm, який досить далеко, RGB поступово реалізується.
Варто зазначити, що RGB - це технологія, яка не обмежується криптовалютою. Вона може бути широко використана в наших не-криптових сценаріях. По мірі того, як протокол стає більш зрілим, ми побачимо все більше та більше випадків використання.
З офіційного вступу ми бачимо функції, які може досягти протокол RGB:
Якщо ми класифікуємо це, ми можемо побачити:
З цієї точки зору RGB дозволяє BTC мати більшість функцій поточного EVM, але він не реалізований у формі, аналогічній до 'сумісного з EVM', але реалізований нативно. Мені треба сказати, що цей набір теорій та дизайнів концептуально крутий.
Фактично, варто зазначити, що RGB система смарт-контрактів відрізняється від попередніх методів, чи то на основі Bitcoin (Кольорові монети, Counterparty, OMNI), чи то не на основі Bitcoin (Ethereum, EOS, тощо), вона має свої власні унікальні особливості:
Перше значення полягає в тому, що смарт-контракти будуть краще стратифіковані. Емітент має права лише на контракт у момент емісії, а потім власник стану матиме права під час процесу постійної еволюції стану;
Друге значення полягає в тому, що воно утримує код поза ланцюжком, що може зекономити місце в ланцюжку, покращити швидкість роботи та зменшити складність розробки, але також може забезпечити безпеку через механізми;
Третій матеріал розкриває свій захисний шар підтримки (блокчейн), і він є повністю тьюрінговим та може підтримувати прості мовні операції.
Отже, наступне зображення може бути ближче до правильного розуміння:
З відео лекції доктора Максима Орловського ми можемо побачити, що офіційно визнані RGB характеристики включають:
Давайте розберемо його по черзі:
1️⃣Надзвичайна конфіденційність
2️⃣Висока безпека
Я не зовсім розумію ці дві точки, мені потрібно вивчити їх.
3️⃣Високомасштабовані
4️⃣Відсутність заторів
5️⃣Надзвичайно висока інтеграція
Отже, насправді, на моїй думці, RGB для BTC більше схожий на наступне:
Порівняно з іншими протоколами, протокол RGB має свої власні дуже унікальні технічні аспекти. Ось декілька важливих частин простої науки:
4.1 Одноразове ущільнення
Ця технологія була запропонована Пітером Тоддом у 2016 році. Її основне значення полягає в тому, щоб "додати печатку до повідомлення, щоб забезпечити, що повідомлення можна використовувати лише один раз, оскільки ви повинні видалити печатку, щоб дізнатися повідомлення".
Простий метод полягає в налаштуванні нотаріального сервера третьої сторони, який публікує сертифікат в загальному реєстрі кожного разу, коли печатка відкривається або блокується, щоб будь-хто міг перевірити статус печатки, яка їм цікава.
Якщо ви не використовуєте довірену сутність для впровадження функції одноразового печаті, ви можете використовувати UTXO Bitcoin як печатку. Оскільки будь-який UTXO в Bitcoin може бути витрачений лише один раз. Тому, використовуючи UTXO як печатку, ви можете заблокувати UTXO при його створенні та відкрити його при його витрачанні.
RGB використовує таку технологію “one-time sealing”, яка “заповіює” інформацію про активи RGB, статус контракту тощо в UTXO. Коли UTXO витрачається, змінюється власність активу та статус контракту. Це означає, що кожного разу, коли відбувається транзакція RGB, відправник фактично створює контракт (той, який визначає права, які передаються).зміна статусу。
Візьмемо RGB20 як приклад:
1️⃣Спочатку емітент контракту встановлює початковий стан контракту та визначає деталі контракту: назву активу, загальний обсяг постачання тощо, та емітент має право переміщати UTXO цих запасів;
2️⃣Коли актив передається вперше, власник першої UTXO може створити зміну стану, щоб визначити, яка UTXO буде утримувати актив;
3️⃣Зміна стану може бути застосована до права зміни власності на актив або до інших типів прав, таких як право на вторинне розміщення чи право на додавання/зміну конкретних властивостей активу (наприклад: метадані) тощо.
4.2 Перевірка клієнта
Перевірка RGB відрізняється від традиційної верифікації «глобальної згоди» та використовує технологію «клієнтської верифікації».
З традиційною перевіркою Bitcoin вузол, підключений до мережі, безперервно завантажує та перевіряє блоки та транзакції у пулі транзакцій (повний вузол). У такого вузла є оновлений в реальному часі вид на набір UTXO на всьому ланцюжку (набір усіх невитрачених виходів на блокчейні). Коли він бачить нову транзакцію, для перевірки її дійсності йому потрібно перевірити тільки те, що всі входи до транзакції є частиною останнього стану набору UTXO.
Але для RGB немає глобально поширених даних, тому немає такого глобального вигляду на набір UTXO. Після того, як клієнт RGB приймає транзакцію, він не тільки повинен перевірити, що останній стан транзакції є дійсним, але також повинен здійснити таку ж перевірку всіх попередніх перетворень стану, пов'язаних з транзакцією, аж до початкового стану випускного контракту.
Це, здається, призводить до очевидної недоліку: Призводить до того, що перевірка займає багато часу
Але це відбувається лише тоді, коли "актив має довгу торгову історію", і ця частина торгової історії може бути підтверджена наперед через шар обміну даними (за добровільною угодою).
Це також приносить значні переваги: Клієнт не повинен знати або перевіряти всі транзакції, які відбуваються глобально
Тому що йому потрібно знати лише транзакції, пов'язані з власним гаманцем, він не повинен перевіряти інші транзакції, тому обсяг даних, які потрібно перевірити кожному клієнту, менший, і масштабованість системи значно покращується.
4.3 обіцянка Біткоіна впевненості
Як RGB запобігає "подвійне витрачання" досягається за допомогою зобов'язань RGB. Такі зобов'язання потрібно реалізувати:
1️⃣Декілька станів, що включають угоду, можуть бути здійснені в одній транзакції Bitcoin
2️⃣Кожен перехід стану контракту може бути закріплений у транзакції Bitcoin лише один раз
Конкретний спосіб досягнення цього полягає в наступному:
1️⃣Спочатку всі державні переходи, пов'язані з певним контрактом (або ідентифікатором активу), повинні бути детерміністично агреговані в зобов'язання
2️⃣Потім зобов'язання всіх переказаних активів агрегуються в дерево Меркла
3️⃣Остаточне значення кореневого хешу - це остаточне зобов'язання RGB;
4️⃣Для забезпечення сумісності з іншими протоколами, які не мають нічого спільного з RGB, але також потребують використання визначених зобов'язань Bitcoin, зобов'язання RGB та зобов'язання інших протоколів повинні бути знову агреговані (як описано в стандарті LNPBP-4), і хеш, отриманий таким чином, значення якого фактично вбудовується у транзакцію Bitcoin.
4.4 Пакетна обробка
Як ми можемо знати з попереднього розділу, ми можемо "заворачувати" будь-яку кількість змін стану в одне зобов'язання Bitcoin, тому теоретично можливе масштабне пакетне оброблення.
Сценарій:A хоче оплатити кількох людей одночасно, передати актив RGB20 B, передати актив RGB21 C та передати власність контракту D
Результат:A лише потрібно створити перехід стану для кожного з B, C та D та зберегти всі переходи стану до тієї ж самої транзакції Bitcoin. Ось і все. Це не потрібно займати більше байтів. Це означає, що маргінальні витрати на ланцюжкові комісії для кожного платежу RGB можуть бути дуже маленькими, оскільки та ж сама комісія рівномірно розподіляється на будь-яку кількість переказів.
Але ми також повинні побачити тут обмеження, а саме: цю інформацію про перехід стану слід «запакувати» в той самий UTXO. Якщо їх кілька, то вхід цієї угоди повинен бути збільшений, а відповідні витрати також покращаться. Але порівняно з традиційною ситуацією, де для кожного потрібна окрема угода, можна досягти великих покращень.
Ця здатність пакетної обробки є дуже важливою для постачальників послуг, які використовують об'єднані UTXO, і буде багато сценаріїв застосування.
4.5 Комунікація між клієнтами
Для завершення перенесення RGB учасники клієнти повинні обмінюватися деякими даними між собою.
Якщо ви маєте докладне розуміння кроків перекладу RGB активів, ви можете знати, що відправник повинен поділитися відправленням з отримувачем (отримувачами). Ця структура даних містить всю необхідну інформацію для перевірки перекладу, включаючи всі переходи стану, які можна прослідкувати до початкового стану контракту.
Відправлення потрібно передати від відправника до одержувача через комунікацію, але протокол RGB не цікавиться каналом зв'язку, використованим для цієї операції обміну даними, оскільки є багато способів це зробити. Однак, в цілому, існують два основних способи обміну даними в програмному забезпеченні RGB:
Після того, як у мене взагалі відбулося загальне уявлення про протокол RGB, я думаю, що на цей момент ми можемо зрозуміти, як протокол розвивався крок за кроком. Будь-яка угода на цьому рівні не досягається протягом однієї ночі і обов'язково пройшла через багато змін та інновацій.
етап уявлення
RGB був початково задуманий Джакомо Цукко і Пітером Тоддом, які запропонували концепції аутентифікації з боку клієнта та одноразового запечатування
етап розробки
Спочатку платформою керували мережа BHB та inbitcoin на протязі певного часу, та підтримувалася групою Посейдон.
Пізніше головним розробником став Алекос Філіні
З середини 2019 року до сьогодні Pandora Core AG та доктор Максим Орловський стали основними учасниками у розвитку технологій
Поступовий етап дорослості
З 2019 року протокол RGB отримав допомогу від багатьох учасників та галузевих організацій і поступово доріс. і це проект, який базується на наборі стандартів, підтримуваних Асоціацією стандартів LNP/BP.
Наприклад: На цьому етапі RGB був перебудований з протоколу токенів у загальну систему смарт-контрактів, поглинувши багато частин конфіденційних транзакцій та використовуючи технологію Blockstream’s bulletproof. Загальна робота була фінансово підтримана Bitfinex/Tether Inc та Fulgur Ventures. (Це також є основою для подальшого розвитку протоколу RGB)
Рекомендації Адама Бека та інженерів Blockstream відіграли важливу роль у технічному проектуванні RGB, включаючи Андрю Поелстру (Bulletproof, mimblewimple, Конфіденційні транзакції), Петера Вулле (Конфіденційні транзакції, Bulletproof) та Крістіана Деккера (Мережа Lightning, Системи) архітектурний дизайн) роботу. Тому це ще одна важлива причина, чому я звертаю увагу на Liquid. На теоретичній основі у них є багато обмінів, і я дуже оптимістично ставлюся до поєднання цих двох в майбутньому.
Основна робота з розробки протоколу RGB майже завершена. У версії v0.10 можна легко використовувати емісію активів та інші функції. Однак виникли деякі проблеми при підключенні до bolt-ln (поточна мережа блискавки bolt), тому було розроблено стандарт bifrost. Протокол використовується для розширення смарт-контрактів та далі пропонує стандарт Storm.
Версія v0.11 в даний момент перебуває на аудиті з безпеки і очікується, що вона буде завершена і випущена до початку 2024 року. Версія v0.11 є важливим оновленням порівняно з v0.10. Контракти між ними точно більше несумісні. Можливо, є плани щодо обміну активами до того часу. Можливо, буде або не буде моста. Усе-таки, поточні версії - це тільки тестові версії.
Я досить очікую, що версія протоколу v0.11 стане великою стабільною версією, яка принесе певний ступінь впевненості у розвитку екологічних проектів під протоколом.
Далі дозвольте мені детально поговорити про існуючі проблеми протоколу RGB:
1️⃣Повільний прогрес у розвитку
Цю проблему критикували багато людей, і причини спричинені багатьма факторами:
—Асоціація LNP/BP має дуже небагато розробників, і основну роботу з кодом виконують доктор Максим та Bitfinex
—LNP/BP є неприбутковою організацією, і її діяльність в основному ґрунтується на пожертвуваннях. Незважаючи на фінансову підтримку від Bitfinex/Tether Inc та Fulgur Ventures, використання коштів також потребує ретельного планування (наприклад, якщо ви хочете проводити офлайн-конференцію щорічно, можливо, у вас не буде бюджету).
2️⃣ Сильна нестабільність
Ця нестабільність посилається на "ступінь, до якої оновлення протоколу можуть ламати старі версії.
Наприклад, цього разу v0.10 спричинить більше невизначеності через ушкодження контракту (несумісність) v0.11.
Якщо екологічні проекти в рамках протоколу розвиватимуть функції на основі v0.10, їм може знадобитися переробка в v0.11, що призведе до великих витрат на ризик. Проте з погляду самої асоціації, це для загального оновлення та планування, і на цьому етапі не буде розглядати це питання.
3️⃣Проблема невідповідності
Сама асоціація вважає загальний план розвитку угоди, який може не обов'язково відповідати потребам ринку.
4️⃣Недостатня увага до коштів
На даний момент дуже мало великих фінансистів звертають увагу на RGB. Інституції все ще занурені в наративи, які можуть бути швидко помічені, такі як написи. Недостатньо уваги приділяється великим і глибоким протоколам, таким як RGB, тому розвиток екології тимчасово не відбувся багато покращень (хоча це краще, ніж раніше, але я особисто вважаю, що це через ефект переливання коштів)
Коли висловлюю свої думки, я дуже люблю давати свої мотиви, оскільки це також основа мого судження; я не люблю видачу наказів та fomo без обдумування, оскільки це не відповідає моїм справжнім намірам. Тож спочатку давайте все це відсортуємо:
Екологічний розвиток BTC є результатом спільної надії поточних майнерів, старих фондів тощо, і на ринку також потрібна нова наративна;
—Основні технічні умови для розвитку екосистеми BTC вже на місці, з яких оновлення taproot є дуже важливою частиною;
—Емісія активів - це перший крок в екологічному розвитку. Без активів нічого не можна зробити. Так ми можемо побачити різні протоколи, що базуються на емісії активів на Bitcoin, і поступово переливаються на інші публічні ланцюжки;
Екологічний розвиток не може бути лише випуском активів, це може бути лише першим кроком. Другим кроком є впровадження сценаріїв застосування для цих активів, тобто обробка та обмін активами і т. д. Це вимагає смарт-контрактів, які можуть бути від простих до складних;
—Щодо поточних протоколів, єдині власні, які я бачив, - це RGB та Bitvm, і, як я вже казав, RGB є більш практичним.
Ось чому я його люблю!
Однак процес розвитку речей часто не є таким послідовним, як уявляється. Давайте використаємо картину, щоб виразити це:
Частина 2: Частина угоди - Розуміння LNP/BP
LNP: Протокол мережі освітлення (Протокол мережі Lightning)
BP: Протокол біткоїна
Це швейцарська некомерційна організація, яка відповідає за нагляд за відкритими стандартами та протоколами 2-го та 3-го рівнів для Bitcoin та мережі Lightning. Вони є творцями протоколів L2 та L3, таких як RGB, Bifrost, Storm, Prometheus, Kaleidscope, та активні учасники у створенні екосистеми #BiFi (Bitcoin Finance) на мережі Lightning. Асоціація складається з@dr-orlovskyі@giacomozuccoЗаснований в 2019 році
Офіційний вебсайт посилання Посилання на Twitterпосилання на github
GitHub містить велику кількість відкритої інформації про RGB та пов'язані протоколи. Технічні друзі можуть докладніше ознайомитися.
LNP/BP має дуже сильний склад організацій-донорів, включаючи:
Крім того, TEDA заявляла багато разів, що вона випустить USDT на протоколі RGB та сприятиме розвитку протоколу RGB!
2.1 LNPBP-1: Публічний ключ
продовження наступить...
Частина Три: Короткий опис часто задаваних питань
У цій частині я продовжу підсумовувати та оновлювати різні питання, пов'язані з технологіями RGB та BTC, з якими я зіткнувся у процесі навчання та управління спільнотою на цьому місці.
Існує чотири основних типи адрес бітової кришки:
1️⃣Адреса легасі/платіжного хешу публічного ключа (P2PKH)
Цей вид традиційної адреси Bitcoin - це форма адреси на момент її створення в перші дні, тому її також називають "спадковою адресою" або "адресою публічного ключа оплати (P2PKH)", оскільки при запуску Bitcoin у 2009 році метод її генерації полягав у створенні пари публічного/приватного ключа, що тоді було єдиним способом створення адреси.
Цей тип адреси починається з «1». Оскільки він займає найбільше місця в транзакціях, він також є найдорожчим типом адреси.
2️⃣Адреса Pay-to-Script-Hash (P2SH)
Цей тип адреси не використовує результат операції хешування відкритого ключа, але використовує операцію хешування певних сценаріїв для фіксації недоліків і може бути використаний для переказів, які потребують кількох підписів тощо.
Цей тип адреси починається з «3», оскільки ви можете використовувати відокремлений свідок для збереження комісії за транзакції, надсилання на адресу P2SH приблизно на 26% дешевше, ніж гаманець, який використовує стару адресу.
3️⃣Адреса з розділеним свідком (SegWit) Адреса Bech32
Адреси Segwit також відомі як адреси Bech32. Цей тип адреси Bitcoin зменшує кількість інформації, збереженої в транзакції. Вони не зберігають підписи та сценарії в транзакції, а у свідку (зобов'язання).
Цей тип адреси починається з «bc1q». Порівняно з P2SH адресами, адреси Segwit можуть заощадити близько 16% від комісії за транзакцію, а порівняно з традиційними адресами - понад 38% комісії.
4️⃣Адреса Taproot
Для підвищення ефективності використання блоку та покращення комісій, SegWit вніс деякі зміни у побудову адрес. Таким чином, на основі адреси SegWit була розроблена адреса Taproot, яка перекладається як основна коренева адреса.
Цей тип адреси починається з «bc1p», що додатково зменшує простір зберігання, покращує ефективність транзакцій та забезпечує кращу конфіденційність.
Це загально використовуваний технічний метод на BTC: HD Гаманець
Ця технологія дозволяє парі «відкритих та приватних ключів» генерувати безліч під-відкритих ключів, які є адресами, які ми бачимо; ця функція призначена для захисту конфіденційності користувачів гаманця Bitcoin.
Оскільки в традиційному використанні, для підтвердження транзакцій користувачі повинні розкривати свої публічні ключі, тому є ризик викриття їх справжньої особистості (яку можна безперервно відстежувати), але після використання HD-гаманця, після кожного використання, конвертуйте його в інший підпублічний ключ, щоб його не можна було відслідкувати.
Для отримання деталей дивіться наступні документи:
HD Гаманці | Ієрархічні детерміновані гаманці
Пояснення того, що таке HD-гаманець, як вони працюють в Bitcoin, та їх історія.
Багато людей будуть сперечатися щодо титулу «перший», тому що людям подобається переслідувати перше
Якщо ви хочете поговорити про перший актив на RGB, то, напевно, він був випущений, коли сам доктор Максим спробував його. Звичайно, ані ви, ані я не бачили цього.
Якщо ви хочете поговорити про зразки RGB, відкриті Асоціацією LNP/BP, ви можете звернутися до наступного веб-сайту
Якщо це актив, випущений на платформі проекту bitmask за протоколом RGB, ви можете звернутися до наступного веб-сайту
Але бітова маска - це лише проектна сторона під протоколом RGB, оскільки RGB є «перевіреним клієнтом», отже, якщо ви зможете побудувати клієнт, ви також зможете використовувати «командний рядок» для видачі свого власного «першого активу RGB».
Отже, я вважаю, що сперечатися про те, хто є номером один, має сенс для короткострокової популярності, але в довгостроковій перспективі більш значущою є цінність, що міститься в активах. Ця цінність може бути духом спільноти, емпауерментом тощо.
Фактично, ви не можете запитати це, оскільки: RGB використовує мережу Bitcoin для «забезпечення безпеки» та «попередження подвійного витрачання». В принципі, його можна використовувати на будь-якій іншій мережі з такими характеристиками.
Якщо транзакція RGB виконується в основній мережі, то її транзакції завантажуються в основну мережу в реальному часі; якщо транзакція RGB виконується в мережі Lightning, то її дані транзакції завантажуються в мережу Lightning в реальному часі, а дані мережі Lightning зберігаються позамережево. Так, воно буде ланцюжене лише в момент виведення на основну мережу BTC; якщо транзакції RGB виконуються в інших мережах, ситуація ланцюгування даних також буде визначатися на основі умов інших мереж.
Треба також вказати, що фактичні дані транзакцій RGB зберігаються на клієнті, а на ланцюжок завантажується сукупність зобов'язань щодо транзакцій.
Для мене RGB - це загальна технологія, яку можна підключити до L1/L2/L3. Вона може зробити багато речей і є дуже важливою частиною розвитку екології BTC; вона може реалізувати BIFI, тобто біткоїн + фі, що може бути defi, nftfi, gamefi або інші форми fi
Фактично, багато людей звертають увагу на застосування RGB в криптовалюті, але RGB може робити більше, наприклад, облігації, скарбничі облігації, поєднання реальних активів та віртуальних активів тощо.
Протокол RGB може працювати в основній мережі, в мережі Lightning та навіть на бічних ланцюгах у майбутньому.
RGB призначений для роботи в мережі Lightning для забезпечення масштабованості. Через виконання розумних контрактів, tps головної мережі очевидно не може відповісти цим вимогам. Високий tps мережі Lightning може, але поточна мережа Lightning Bolt не може. Вона задовольняє складні вимоги розумних контрактів RGB, тому її потрібно оновити до bifrost, щоб стати повноцінною;
Поточна проблема пов'язана з розміром каналу мережі Lightning, і мережу Lightning спочатку розроблено для невеликих платежів; звісно, якщо ви побудуєте великий канал самостійно, ви також зможете робити великі платежі (зазвичай великі суми йдуть на головну мережу) )
Я думаю, є дві причини, чому мережу Lightning використовують замість бічних ланцюжків:
1️⃣ Бічні ланцюги, як правило, вважаються недостатньо місцевими, оскільки вони мають власний ланцюг, власні вузли, власні блоки та власний механізм згоди. Можна навіть сказати, що вони мають мало спільного з головною мережею BTC; але мережу Lightning можна розглядати як щось, що звисає на головній мережі BTC. Вона дуже місцева і називається L2.
2️⃣Теоретична TPS мережі Lightning набагато вища, ніж у бічному ланцюжку
У мене також є така ж побоювання, особливо оскільки на даний момент здається, що пожертв дуже мало (насправді, рівень прибутку від інвестицій, таких як TEDA, дуже високий), але я все ще ціную дух асоціації у безприбутковому способі. Робити такі великі речі.
Головним чином, більшість роботи над протоколом RGB вже завершена. Звичайно, є ще багато завдань, які слід виконати; Я думаю, якщо протокол RGB привертає увагу все більшої кількості людей, із збільшенням кількості розробників, робота над розвитком зміниться. швидко.
Так, і кілька разів
За даними на 17 грудня 2023 року всі чекають оновлення v0.11. Це оновлення передбачає оновлення смарт-контрактів, гаманців і т.д .; ми сподіваємося, що v0.11 стане більш стабільною версією, щоб проекти в екосистемі могли розвиватися відносно безпечно.
Якщо випущено v0.11, випуск та переказ активів RGB на основі Мережі Молний скоро будуть реалізовані (це буде дуже швидко), але складні смарт-контракти все ще покладаються на розвиток мережі Молния bifrost.
bitmask/bitlight: Два дуже формальні проектні сторони. Перша була оголошена на домашній сторінці LNP/BP і фокусується на розвитку гаманців та діба (nft ринок). Друга фокусується на розвитку гаманців та дексу;
pprgb: Перший rgb-мем з ринковою популярністю, проект тимчасово випущений на Liquid (зверніть увагу на атрибутивне)
печатка: Проекти, які сподіваються випустити NFT та надати токени на rgb, наполягають на випуску на rgb
UTXO exchange: Я хочу побудувати dex на rgb та використовувати zero-roll airdrops. Активи, які вона випускає, повинні бути активами rgb. Однак, враховуючи поточну форму, ймовірно, вона буде в централізованій формі та оцінюватиме ризики самостійно.
BiHelix: Спочатку названий Infinity, потім перейменований у Intas, а пізніше в Bihelix. Я написав багато статей і зробив багато евангельської роботи, але на початкових етапах виникли деякі неприємності з угодою LNP/BP і його визначили як шахрайство. Я пропоную їм добре вирішити цю проблему, інакше буде складніше рухатися по цьому шляху.
rgbdoge: Припускають, що це китайський проєкт (мені байдуже, чи це китайський, чи іноземний, це залежить від якості та стратегії проєкту). Він має сильну діяльність, але не має напрямку (від початкової битви за «перше місце», до побудови платформи, до випуску на ліквідність).
bitrgb: Платформа для створення RGB смарт-контрактів. Зараз вона використовує метод nostrasset. Раніше я рекомендував завдання zealy (ідея Lubai), але, враховуючи "анонімність команди / анонімність інвестиційних установ / заряд м'яти (ціна, схоже, не низька)", відчуваю, що ризик дуже великий.
Нещодавно було виявлено, що LNP/BP tg було визнано шахрайством доктором Максимом.
Inscriptionwar: Це повністю безкоштовно, тому не потрібно брати участь.
Безпека поза ланцюжком залежить від сторони проекту або самого клієнта, тому асоціація повинна встановити єдино стандарти для зберігання, тощо, щоб забезпечити безпеку активів тощо.
Основні дані зберігаються на клієнті поза ланцюжком, а клієнти можуть ділитися інформацією та спілкуватися через вузли Storm у майбутньому.
Дозвольте мені надати короткий вступ. Адам Бек заснував компанію Blockstream. У цій компанії є багато продуктів, таких як платформа розробки бічного ланцюжка elements. Вони також мають продукти green wallet, справжні пули для майнінгу та фінансові продукти, пов'язані з пулами майнінгу. Фінансові продукти тощо;
Liquid - це L2, розроблений за допомогою платформи elements, а sideswap - це проект на Liquid.
Збереження безпеки офлайн-даних забезпечується стороною проекту. Користувачі можуть захистити безпеку своїх активів, роблячи резервні копії даних. Звісно, якщо виникнуть проблеми з даними сторони проекту, а користувач не зробив резервну копію даних, то виникнуть проблеми з активами.
Деякі зловмисні проекти можуть вчиняти злочини, створюючи шкідливе програмне забезпечення, але механізм використання RGB може уникнути шахрайства механізму. Звичайно, RGB важко запобігти у всіх блокчейнах.
Так, використовуючи протокол Storm, дані діляться між ровесниками, але поточний розвиток запізнюється
Не може. Проектна сторона не може збирати інформацію про окремі транзакції і може збирати лише кількість завершених переказів у межах додатка (наприклад, загальні статистичні дані).
Звісно, я особисто вважаю, що якщо користувач авторизує відповідні дозволи, то програма може отримати доступ до цих даних (це буде трохи схоже на розкриття ключа на Liquid для перегляду прихованої інформації)
Так, але кожна компанія повинна дотримуватися вимог щодо цінних паперів.
1) Актив має ідентифікатор контракту та початкове значення генезису
2) Сумісний з гаманцем RGB
3) Відкритий код
Цим чином ви можете знати, чи це є активом RGB
UTXO - це шар "публічних" активів, але тільки між однаковими активами, наприклад: USDT<>USDT; у майбутньому ми зможемо досягнути "взаємодії" між різними активами, але для цього потрібен Bifrost
Це можливо, але цільовий ланцюг повинен підтримувати модель UTXO та інші доступні моделі для інтеграції з ядром RGB та хрестовими бібліотеками. На даний момент активи повинні відповідати специфікаціям моделі RGB20.
Фактично, RGB сумісний з LN, і ви можете використовувати його з будь-якою реалізацією LN, такою як вставка CLN або LND. При використанні Storm можливе підтвердження кожного зразка на LN; на L1 підтвердження та маршрутизація активів відбувається лише в разі відкриття / закриття каналу або сканування за допомогою HTLC.
Так, для цього потрібно багато бібліотек підтримки, які працюватимуть разом,
У теорії процес може бути спрощений через авторизацію. Звичайно, це лише у теорії.
Частина 4: Посилання на джерела
Тут ви можете дізнатися:
1️⃣Що таке RGB, що воно може робити, і які його переваги ( Стрибати)
2️⃣Як спробувати бібліотеку RGB, таку як командний рядок, встановлення вузлів, виклик API тощо. (Стрибок)
3️⃣Навчайтеся RGB через офіційні відео (звичайно, це важко для нерідкомовців) (Стрибок)
Масштабовані & конфіденційні смарт-контракти для Bitcoin & Lightning
У цьому документі пояснюються принципи дизайну та надаються глибокі технічні відомості про те, як побудовані та працюють системи RGB, включно з:
1️⃣Огляд та цілі проектування протоколу (Стрибок)
2️⃣Вступ до “Перевірки клієнта”, опис “Одноразових печаток” та”Визначених біткойн зобов’язань”(Стрибок)
3️⃣Пояснення “RGB Contract, Status і Operation” ( Стрибок)
4️⃣Деякий вміст «Спробуйте контракт RGB»: включаючи написання контрактів, взаємодію з контрактами, комунікацію P2P, взаємодію з гаманцями тощо. (Стрибок)
RGB Чорнопапір | RGB Чорнопапір
Повний, масштабований та конфіденційний рівень смарт-контрактів для Bitcoin та LN
Якщо ви зіткнетесь з проблемами, спочатку перевірте, чи цей офіційний документ має відповіді.
Тут ви можете дізнатися про машину Алу, що є повноцінною тьюрінговою машиною, розроблену Асоціацією LNP/BP
1️⃣Дослідження CoinEx
Короткий аналіз RGB: масштабований, конфіденційний протокол розумного контракту, побудований на Bitcoin
Блог | CoinEx - Глобальна криптовалютна біржа
2️⃣Федеріко Тенґа
Розуміння протоколу RGB
@FedericoTenga">Федеріко Тенга – Medium
@FedericoTenga">Читайте тексти Федеріко Тенга на Medium. Працюю над річами Bitcoin. Кожен день, Федеріко Тенга та тисячі інших голосів ре...
@FedericoTenga"medium.com
3️⃣Bitfinex
Як RGB може покращити Біткоін?
Як RGB може покращити біткоїн? - Блог Bitfinex
4️⃣Waterdrip Capital
Детальне пояснення протоколу RGB: знаходження нового способу створення нового другого рівня емісії біткойн-активів
5️⃣ Дизайн протоколу RGB
Місце зібрання китайських ідей про Bitcoin
Compartilhar
Conteúdo
Багато людей починають звертати увагу на RGB-протокол Bitcoin та дійсно в захваті. Однак більшість людей досить незнайома з таким протоколом (особливо з технічно складним протоколом) і не знають, як досліджувати та спробувати вміст та екологію протоколу.
Отже, я спеціально пишу постійно оновлюваний дзеркало, щоб узагальнити відповідні навчальні матеріали та забезпечити відносно раціональний шлях навчання; в той же час воно також служить як запис особистого навчання про RGB.
Частина перша: Популярна наука Частина-початкове розуміння RGB
Коли багато людей бачать три слова RGB, вони думають про "три основні кольори: червоний, зелений, синій". Якщо ви подивитеся на піктограму, це дійсно так. Це тому, що протокол RGB використовує ранню концепцію "фарбованих монет".
Тут ми говоримо про RGB - це угода, дуже приватна, масштабована система протоколу розумного контракту, яка може працювати в мережі Bitcoin, мережі Lightning або подібних мережах.
Даний протокол наразі підтримується та оновлюється протоколом LNP/BP, а також біржа Gate бере участь у деяких роботах з кодом.
Важко просто класифікувати RGB в категорію Bitcoin L2. У нього немає власного ланцюжка, він не має власного шару, і може функціонувати на інших L2s BTC. Тому, щоб бути точними: Це універсальна технологія.
У галузі загалом вважають, що RGB та Bitvm стануть кінцевою формою розширення BTC, оскільки вони обидва можуть досягти масштабованості екосистеми BTC на основі внутрішньої природи BTC. Порівняно з Bitvm, який досить далеко, RGB поступово реалізується.
Варто зазначити, що RGB - це технологія, яка не обмежується криптовалютою. Вона може бути широко використана в наших не-криптових сценаріях. По мірі того, як протокол стає більш зрілим, ми побачимо все більше та більше випадків використання.
З офіційного вступу ми бачимо функції, які може досягти протокол RGB:
Якщо ми класифікуємо це, ми можемо побачити:
З цієї точки зору RGB дозволяє BTC мати більшість функцій поточного EVM, але він не реалізований у формі, аналогічній до 'сумісного з EVM', але реалізований нативно. Мені треба сказати, що цей набір теорій та дизайнів концептуально крутий.
Фактично, варто зазначити, що RGB система смарт-контрактів відрізняється від попередніх методів, чи то на основі Bitcoin (Кольорові монети, Counterparty, OMNI), чи то не на основі Bitcoin (Ethereum, EOS, тощо), вона має свої власні унікальні особливості:
Перше значення полягає в тому, що смарт-контракти будуть краще стратифіковані. Емітент має права лише на контракт у момент емісії, а потім власник стану матиме права під час процесу постійної еволюції стану;
Друге значення полягає в тому, що воно утримує код поза ланцюжком, що може зекономити місце в ланцюжку, покращити швидкість роботи та зменшити складність розробки, але також може забезпечити безпеку через механізми;
Третій матеріал розкриває свій захисний шар підтримки (блокчейн), і він є повністю тьюрінговим та може підтримувати прості мовні операції.
Отже, наступне зображення може бути ближче до правильного розуміння:
З відео лекції доктора Максима Орловського ми можемо побачити, що офіційно визнані RGB характеристики включають:
Давайте розберемо його по черзі:
1️⃣Надзвичайна конфіденційність
2️⃣Висока безпека
Я не зовсім розумію ці дві точки, мені потрібно вивчити їх.
3️⃣Високомасштабовані
4️⃣Відсутність заторів
5️⃣Надзвичайно висока інтеграція
Отже, насправді, на моїй думці, RGB для BTC більше схожий на наступне:
Порівняно з іншими протоколами, протокол RGB має свої власні дуже унікальні технічні аспекти. Ось декілька важливих частин простої науки:
4.1 Одноразове ущільнення
Ця технологія була запропонована Пітером Тоддом у 2016 році. Її основне значення полягає в тому, щоб "додати печатку до повідомлення, щоб забезпечити, що повідомлення можна використовувати лише один раз, оскільки ви повинні видалити печатку, щоб дізнатися повідомлення".
Простий метод полягає в налаштуванні нотаріального сервера третьої сторони, який публікує сертифікат в загальному реєстрі кожного разу, коли печатка відкривається або блокується, щоб будь-хто міг перевірити статус печатки, яка їм цікава.
Якщо ви не використовуєте довірену сутність для впровадження функції одноразового печаті, ви можете використовувати UTXO Bitcoin як печатку. Оскільки будь-який UTXO в Bitcoin може бути витрачений лише один раз. Тому, використовуючи UTXO як печатку, ви можете заблокувати UTXO при його створенні та відкрити його при його витрачанні.
RGB використовує таку технологію “one-time sealing”, яка “заповіює” інформацію про активи RGB, статус контракту тощо в UTXO. Коли UTXO витрачається, змінюється власність активу та статус контракту. Це означає, що кожного разу, коли відбувається транзакція RGB, відправник фактично створює контракт (той, який визначає права, які передаються).зміна статусу。
Візьмемо RGB20 як приклад:
1️⃣Спочатку емітент контракту встановлює початковий стан контракту та визначає деталі контракту: назву активу, загальний обсяг постачання тощо, та емітент має право переміщати UTXO цих запасів;
2️⃣Коли актив передається вперше, власник першої UTXO може створити зміну стану, щоб визначити, яка UTXO буде утримувати актив;
3️⃣Зміна стану може бути застосована до права зміни власності на актив або до інших типів прав, таких як право на вторинне розміщення чи право на додавання/зміну конкретних властивостей активу (наприклад: метадані) тощо.
4.2 Перевірка клієнта
Перевірка RGB відрізняється від традиційної верифікації «глобальної згоди» та використовує технологію «клієнтської верифікації».
З традиційною перевіркою Bitcoin вузол, підключений до мережі, безперервно завантажує та перевіряє блоки та транзакції у пулі транзакцій (повний вузол). У такого вузла є оновлений в реальному часі вид на набір UTXO на всьому ланцюжку (набір усіх невитрачених виходів на блокчейні). Коли він бачить нову транзакцію, для перевірки її дійсності йому потрібно перевірити тільки те, що всі входи до транзакції є частиною останнього стану набору UTXO.
Але для RGB немає глобально поширених даних, тому немає такого глобального вигляду на набір UTXO. Після того, як клієнт RGB приймає транзакцію, він не тільки повинен перевірити, що останній стан транзакції є дійсним, але також повинен здійснити таку ж перевірку всіх попередніх перетворень стану, пов'язаних з транзакцією, аж до початкового стану випускного контракту.
Це, здається, призводить до очевидної недоліку: Призводить до того, що перевірка займає багато часу
Але це відбувається лише тоді, коли "актив має довгу торгову історію", і ця частина торгової історії може бути підтверджена наперед через шар обміну даними (за добровільною угодою).
Це також приносить значні переваги: Клієнт не повинен знати або перевіряти всі транзакції, які відбуваються глобально
Тому що йому потрібно знати лише транзакції, пов'язані з власним гаманцем, він не повинен перевіряти інші транзакції, тому обсяг даних, які потрібно перевірити кожному клієнту, менший, і масштабованість системи значно покращується.
4.3 обіцянка Біткоіна впевненості
Як RGB запобігає "подвійне витрачання" досягається за допомогою зобов'язань RGB. Такі зобов'язання потрібно реалізувати:
1️⃣Декілька станів, що включають угоду, можуть бути здійснені в одній транзакції Bitcoin
2️⃣Кожен перехід стану контракту може бути закріплений у транзакції Bitcoin лише один раз
Конкретний спосіб досягнення цього полягає в наступному:
1️⃣Спочатку всі державні переходи, пов'язані з певним контрактом (або ідентифікатором активу), повинні бути детерміністично агреговані в зобов'язання
2️⃣Потім зобов'язання всіх переказаних активів агрегуються в дерево Меркла
3️⃣Остаточне значення кореневого хешу - це остаточне зобов'язання RGB;
4️⃣Для забезпечення сумісності з іншими протоколами, які не мають нічого спільного з RGB, але також потребують використання визначених зобов'язань Bitcoin, зобов'язання RGB та зобов'язання інших протоколів повинні бути знову агреговані (як описано в стандарті LNPBP-4), і хеш, отриманий таким чином, значення якого фактично вбудовується у транзакцію Bitcoin.
4.4 Пакетна обробка
Як ми можемо знати з попереднього розділу, ми можемо "заворачувати" будь-яку кількість змін стану в одне зобов'язання Bitcoin, тому теоретично можливе масштабне пакетне оброблення.
Сценарій:A хоче оплатити кількох людей одночасно, передати актив RGB20 B, передати актив RGB21 C та передати власність контракту D
Результат:A лише потрібно створити перехід стану для кожного з B, C та D та зберегти всі переходи стану до тієї ж самої транзакції Bitcoin. Ось і все. Це не потрібно займати більше байтів. Це означає, що маргінальні витрати на ланцюжкові комісії для кожного платежу RGB можуть бути дуже маленькими, оскільки та ж сама комісія рівномірно розподіляється на будь-яку кількість переказів.
Але ми також повинні побачити тут обмеження, а саме: цю інформацію про перехід стану слід «запакувати» в той самий UTXO. Якщо їх кілька, то вхід цієї угоди повинен бути збільшений, а відповідні витрати також покращаться. Але порівняно з традиційною ситуацією, де для кожного потрібна окрема угода, можна досягти великих покращень.
Ця здатність пакетної обробки є дуже важливою для постачальників послуг, які використовують об'єднані UTXO, і буде багато сценаріїв застосування.
4.5 Комунікація між клієнтами
Для завершення перенесення RGB учасники клієнти повинні обмінюватися деякими даними між собою.
Якщо ви маєте докладне розуміння кроків перекладу RGB активів, ви можете знати, що відправник повинен поділитися відправленням з отримувачем (отримувачами). Ця структура даних містить всю необхідну інформацію для перевірки перекладу, включаючи всі переходи стану, які можна прослідкувати до початкового стану контракту.
Відправлення потрібно передати від відправника до одержувача через комунікацію, але протокол RGB не цікавиться каналом зв'язку, використованим для цієї операції обміну даними, оскільки є багато способів це зробити. Однак, в цілому, існують два основних способи обміну даними в програмному забезпеченні RGB:
Після того, як у мене взагалі відбулося загальне уявлення про протокол RGB, я думаю, що на цей момент ми можемо зрозуміти, як протокол розвивався крок за кроком. Будь-яка угода на цьому рівні не досягається протягом однієї ночі і обов'язково пройшла через багато змін та інновацій.
етап уявлення
RGB був початково задуманий Джакомо Цукко і Пітером Тоддом, які запропонували концепції аутентифікації з боку клієнта та одноразового запечатування
етап розробки
Спочатку платформою керували мережа BHB та inbitcoin на протязі певного часу, та підтримувалася групою Посейдон.
Пізніше головним розробником став Алекос Філіні
З середини 2019 року до сьогодні Pandora Core AG та доктор Максим Орловський стали основними учасниками у розвитку технологій
Поступовий етап дорослості
З 2019 року протокол RGB отримав допомогу від багатьох учасників та галузевих організацій і поступово доріс. і це проект, який базується на наборі стандартів, підтримуваних Асоціацією стандартів LNP/BP.
Наприклад: На цьому етапі RGB був перебудований з протоколу токенів у загальну систему смарт-контрактів, поглинувши багато частин конфіденційних транзакцій та використовуючи технологію Blockstream’s bulletproof. Загальна робота була фінансово підтримана Bitfinex/Tether Inc та Fulgur Ventures. (Це також є основою для подальшого розвитку протоколу RGB)
Рекомендації Адама Бека та інженерів Blockstream відіграли важливу роль у технічному проектуванні RGB, включаючи Андрю Поелстру (Bulletproof, mimblewimple, Конфіденційні транзакції), Петера Вулле (Конфіденційні транзакції, Bulletproof) та Крістіана Деккера (Мережа Lightning, Системи) архітектурний дизайн) роботу. Тому це ще одна важлива причина, чому я звертаю увагу на Liquid. На теоретичній основі у них є багато обмінів, і я дуже оптимістично ставлюся до поєднання цих двох в майбутньому.
Основна робота з розробки протоколу RGB майже завершена. У версії v0.10 можна легко використовувати емісію активів та інші функції. Однак виникли деякі проблеми при підключенні до bolt-ln (поточна мережа блискавки bolt), тому було розроблено стандарт bifrost. Протокол використовується для розширення смарт-контрактів та далі пропонує стандарт Storm.
Версія v0.11 в даний момент перебуває на аудиті з безпеки і очікується, що вона буде завершена і випущена до початку 2024 року. Версія v0.11 є важливим оновленням порівняно з v0.10. Контракти між ними точно більше несумісні. Можливо, є плани щодо обміну активами до того часу. Можливо, буде або не буде моста. Усе-таки, поточні версії - це тільки тестові версії.
Я досить очікую, що версія протоколу v0.11 стане великою стабільною версією, яка принесе певний ступінь впевненості у розвитку екологічних проектів під протоколом.
Далі дозвольте мені детально поговорити про існуючі проблеми протоколу RGB:
1️⃣Повільний прогрес у розвитку
Цю проблему критикували багато людей, і причини спричинені багатьма факторами:
—Асоціація LNP/BP має дуже небагато розробників, і основну роботу з кодом виконують доктор Максим та Bitfinex
—LNP/BP є неприбутковою організацією, і її діяльність в основному ґрунтується на пожертвуваннях. Незважаючи на фінансову підтримку від Bitfinex/Tether Inc та Fulgur Ventures, використання коштів також потребує ретельного планування (наприклад, якщо ви хочете проводити офлайн-конференцію щорічно, можливо, у вас не буде бюджету).
2️⃣ Сильна нестабільність
Ця нестабільність посилається на "ступінь, до якої оновлення протоколу можуть ламати старі версії.
Наприклад, цього разу v0.10 спричинить більше невизначеності через ушкодження контракту (несумісність) v0.11.
Якщо екологічні проекти в рамках протоколу розвиватимуть функції на основі v0.10, їм може знадобитися переробка в v0.11, що призведе до великих витрат на ризик. Проте з погляду самої асоціації, це для загального оновлення та планування, і на цьому етапі не буде розглядати це питання.
3️⃣Проблема невідповідності
Сама асоціація вважає загальний план розвитку угоди, який може не обов'язково відповідати потребам ринку.
4️⃣Недостатня увага до коштів
На даний момент дуже мало великих фінансистів звертають увагу на RGB. Інституції все ще занурені в наративи, які можуть бути швидко помічені, такі як написи. Недостатньо уваги приділяється великим і глибоким протоколам, таким як RGB, тому розвиток екології тимчасово не відбувся багато покращень (хоча це краще, ніж раніше, але я особисто вважаю, що це через ефект переливання коштів)
Коли висловлюю свої думки, я дуже люблю давати свої мотиви, оскільки це також основа мого судження; я не люблю видачу наказів та fomo без обдумування, оскільки це не відповідає моїм справжнім намірам. Тож спочатку давайте все це відсортуємо:
Екологічний розвиток BTC є результатом спільної надії поточних майнерів, старих фондів тощо, і на ринку також потрібна нова наративна;
—Основні технічні умови для розвитку екосистеми BTC вже на місці, з яких оновлення taproot є дуже важливою частиною;
—Емісія активів - це перший крок в екологічному розвитку. Без активів нічого не можна зробити. Так ми можемо побачити різні протоколи, що базуються на емісії активів на Bitcoin, і поступово переливаються на інші публічні ланцюжки;
Екологічний розвиток не може бути лише випуском активів, це може бути лише першим кроком. Другим кроком є впровадження сценаріїв застосування для цих активів, тобто обробка та обмін активами і т. д. Це вимагає смарт-контрактів, які можуть бути від простих до складних;
—Щодо поточних протоколів, єдині власні, які я бачив, - це RGB та Bitvm, і, як я вже казав, RGB є більш практичним.
Ось чому я його люблю!
Однак процес розвитку речей часто не є таким послідовним, як уявляється. Давайте використаємо картину, щоб виразити це:
Частина 2: Частина угоди - Розуміння LNP/BP
LNP: Протокол мережі освітлення (Протокол мережі Lightning)
BP: Протокол біткоїна
Це швейцарська некомерційна організація, яка відповідає за нагляд за відкритими стандартами та протоколами 2-го та 3-го рівнів для Bitcoin та мережі Lightning. Вони є творцями протоколів L2 та L3, таких як RGB, Bifrost, Storm, Prometheus, Kaleidscope, та активні учасники у створенні екосистеми #BiFi (Bitcoin Finance) на мережі Lightning. Асоціація складається з@dr-orlovskyі@giacomozuccoЗаснований в 2019 році
Офіційний вебсайт посилання Посилання на Twitterпосилання на github
GitHub містить велику кількість відкритої інформації про RGB та пов'язані протоколи. Технічні друзі можуть докладніше ознайомитися.
LNP/BP має дуже сильний склад організацій-донорів, включаючи:
Крім того, TEDA заявляла багато разів, що вона випустить USDT на протоколі RGB та сприятиме розвитку протоколу RGB!
2.1 LNPBP-1: Публічний ключ
продовження наступить...
Частина Три: Короткий опис часто задаваних питань
У цій частині я продовжу підсумовувати та оновлювати різні питання, пов'язані з технологіями RGB та BTC, з якими я зіткнувся у процесі навчання та управління спільнотою на цьому місці.
Існує чотири основних типи адрес бітової кришки:
1️⃣Адреса легасі/платіжного хешу публічного ключа (P2PKH)
Цей вид традиційної адреси Bitcoin - це форма адреси на момент її створення в перші дні, тому її також називають "спадковою адресою" або "адресою публічного ключа оплати (P2PKH)", оскільки при запуску Bitcoin у 2009 році метод її генерації полягав у створенні пари публічного/приватного ключа, що тоді було єдиним способом створення адреси.
Цей тип адреси починається з «1». Оскільки він займає найбільше місця в транзакціях, він також є найдорожчим типом адреси.
2️⃣Адреса Pay-to-Script-Hash (P2SH)
Цей тип адреси не використовує результат операції хешування відкритого ключа, але використовує операцію хешування певних сценаріїв для фіксації недоліків і може бути використаний для переказів, які потребують кількох підписів тощо.
Цей тип адреси починається з «3», оскільки ви можете використовувати відокремлений свідок для збереження комісії за транзакції, надсилання на адресу P2SH приблизно на 26% дешевше, ніж гаманець, який використовує стару адресу.
3️⃣Адреса з розділеним свідком (SegWit) Адреса Bech32
Адреси Segwit також відомі як адреси Bech32. Цей тип адреси Bitcoin зменшує кількість інформації, збереженої в транзакції. Вони не зберігають підписи та сценарії в транзакції, а у свідку (зобов'язання).
Цей тип адреси починається з «bc1q». Порівняно з P2SH адресами, адреси Segwit можуть заощадити близько 16% від комісії за транзакцію, а порівняно з традиційними адресами - понад 38% комісії.
4️⃣Адреса Taproot
Для підвищення ефективності використання блоку та покращення комісій, SegWit вніс деякі зміни у побудову адрес. Таким чином, на основі адреси SegWit була розроблена адреса Taproot, яка перекладається як основна коренева адреса.
Цей тип адреси починається з «bc1p», що додатково зменшує простір зберігання, покращує ефективність транзакцій та забезпечує кращу конфіденційність.
Це загально використовуваний технічний метод на BTC: HD Гаманець
Ця технологія дозволяє парі «відкритих та приватних ключів» генерувати безліч під-відкритих ключів, які є адресами, які ми бачимо; ця функція призначена для захисту конфіденційності користувачів гаманця Bitcoin.
Оскільки в традиційному використанні, для підтвердження транзакцій користувачі повинні розкривати свої публічні ключі, тому є ризик викриття їх справжньої особистості (яку можна безперервно відстежувати), але після використання HD-гаманця, після кожного використання, конвертуйте його в інший підпублічний ключ, щоб його не можна було відслідкувати.
Для отримання деталей дивіться наступні документи:
HD Гаманці | Ієрархічні детерміновані гаманці
Пояснення того, що таке HD-гаманець, як вони працюють в Bitcoin, та їх історія.
Багато людей будуть сперечатися щодо титулу «перший», тому що людям подобається переслідувати перше
Якщо ви хочете поговорити про перший актив на RGB, то, напевно, він був випущений, коли сам доктор Максим спробував його. Звичайно, ані ви, ані я не бачили цього.
Якщо ви хочете поговорити про зразки RGB, відкриті Асоціацією LNP/BP, ви можете звернутися до наступного веб-сайту
Якщо це актив, випущений на платформі проекту bitmask за протоколом RGB, ви можете звернутися до наступного веб-сайту
Але бітова маска - це лише проектна сторона під протоколом RGB, оскільки RGB є «перевіреним клієнтом», отже, якщо ви зможете побудувати клієнт, ви також зможете використовувати «командний рядок» для видачі свого власного «першого активу RGB».
Отже, я вважаю, що сперечатися про те, хто є номером один, має сенс для короткострокової популярності, але в довгостроковій перспективі більш значущою є цінність, що міститься в активах. Ця цінність може бути духом спільноти, емпауерментом тощо.
Фактично, ви не можете запитати це, оскільки: RGB використовує мережу Bitcoin для «забезпечення безпеки» та «попередження подвійного витрачання». В принципі, його можна використовувати на будь-якій іншій мережі з такими характеристиками.
Якщо транзакція RGB виконується в основній мережі, то її транзакції завантажуються в основну мережу в реальному часі; якщо транзакція RGB виконується в мережі Lightning, то її дані транзакції завантажуються в мережу Lightning в реальному часі, а дані мережі Lightning зберігаються позамережево. Так, воно буде ланцюжене лише в момент виведення на основну мережу BTC; якщо транзакції RGB виконуються в інших мережах, ситуація ланцюгування даних також буде визначатися на основі умов інших мереж.
Треба також вказати, що фактичні дані транзакцій RGB зберігаються на клієнті, а на ланцюжок завантажується сукупність зобов'язань щодо транзакцій.
Для мене RGB - це загальна технологія, яку можна підключити до L1/L2/L3. Вона може зробити багато речей і є дуже важливою частиною розвитку екології BTC; вона може реалізувати BIFI, тобто біткоїн + фі, що може бути defi, nftfi, gamefi або інші форми fi
Фактично, багато людей звертають увагу на застосування RGB в криптовалюті, але RGB може робити більше, наприклад, облігації, скарбничі облігації, поєднання реальних активів та віртуальних активів тощо.
Протокол RGB може працювати в основній мережі, в мережі Lightning та навіть на бічних ланцюгах у майбутньому.
RGB призначений для роботи в мережі Lightning для забезпечення масштабованості. Через виконання розумних контрактів, tps головної мережі очевидно не може відповісти цим вимогам. Високий tps мережі Lightning може, але поточна мережа Lightning Bolt не може. Вона задовольняє складні вимоги розумних контрактів RGB, тому її потрібно оновити до bifrost, щоб стати повноцінною;
Поточна проблема пов'язана з розміром каналу мережі Lightning, і мережу Lightning спочатку розроблено для невеликих платежів; звісно, якщо ви побудуєте великий канал самостійно, ви також зможете робити великі платежі (зазвичай великі суми йдуть на головну мережу) )
Я думаю, є дві причини, чому мережу Lightning використовують замість бічних ланцюжків:
1️⃣ Бічні ланцюги, як правило, вважаються недостатньо місцевими, оскільки вони мають власний ланцюг, власні вузли, власні блоки та власний механізм згоди. Можна навіть сказати, що вони мають мало спільного з головною мережею BTC; але мережу Lightning можна розглядати як щось, що звисає на головній мережі BTC. Вона дуже місцева і називається L2.
2️⃣Теоретична TPS мережі Lightning набагато вища, ніж у бічному ланцюжку
У мене також є така ж побоювання, особливо оскільки на даний момент здається, що пожертв дуже мало (насправді, рівень прибутку від інвестицій, таких як TEDA, дуже високий), але я все ще ціную дух асоціації у безприбутковому способі. Робити такі великі речі.
Головним чином, більшість роботи над протоколом RGB вже завершена. Звичайно, є ще багато завдань, які слід виконати; Я думаю, якщо протокол RGB привертає увагу все більшої кількості людей, із збільшенням кількості розробників, робота над розвитком зміниться. швидко.
Так, і кілька разів
За даними на 17 грудня 2023 року всі чекають оновлення v0.11. Це оновлення передбачає оновлення смарт-контрактів, гаманців і т.д .; ми сподіваємося, що v0.11 стане більш стабільною версією, щоб проекти в екосистемі могли розвиватися відносно безпечно.
Якщо випущено v0.11, випуск та переказ активів RGB на основі Мережі Молний скоро будуть реалізовані (це буде дуже швидко), але складні смарт-контракти все ще покладаються на розвиток мережі Молния bifrost.
bitmask/bitlight: Два дуже формальні проектні сторони. Перша була оголошена на домашній сторінці LNP/BP і фокусується на розвитку гаманців та діба (nft ринок). Друга фокусується на розвитку гаманців та дексу;
pprgb: Перший rgb-мем з ринковою популярністю, проект тимчасово випущений на Liquid (зверніть увагу на атрибутивне)
печатка: Проекти, які сподіваються випустити NFT та надати токени на rgb, наполягають на випуску на rgb
UTXO exchange: Я хочу побудувати dex на rgb та використовувати zero-roll airdrops. Активи, які вона випускає, повинні бути активами rgb. Однак, враховуючи поточну форму, ймовірно, вона буде в централізованій формі та оцінюватиме ризики самостійно.
BiHelix: Спочатку названий Infinity, потім перейменований у Intas, а пізніше в Bihelix. Я написав багато статей і зробив багато евангельської роботи, але на початкових етапах виникли деякі неприємності з угодою LNP/BP і його визначили як шахрайство. Я пропоную їм добре вирішити цю проблему, інакше буде складніше рухатися по цьому шляху.
rgbdoge: Припускають, що це китайський проєкт (мені байдуже, чи це китайський, чи іноземний, це залежить від якості та стратегії проєкту). Він має сильну діяльність, але не має напрямку (від початкової битви за «перше місце», до побудови платформи, до випуску на ліквідність).
bitrgb: Платформа для створення RGB смарт-контрактів. Зараз вона використовує метод nostrasset. Раніше я рекомендував завдання zealy (ідея Lubai), але, враховуючи "анонімність команди / анонімність інвестиційних установ / заряд м'яти (ціна, схоже, не низька)", відчуваю, що ризик дуже великий.
Нещодавно було виявлено, що LNP/BP tg було визнано шахрайством доктором Максимом.
Inscriptionwar: Це повністю безкоштовно, тому не потрібно брати участь.
Безпека поза ланцюжком залежить від сторони проекту або самого клієнта, тому асоціація повинна встановити єдино стандарти для зберігання, тощо, щоб забезпечити безпеку активів тощо.
Основні дані зберігаються на клієнті поза ланцюжком, а клієнти можуть ділитися інформацією та спілкуватися через вузли Storm у майбутньому.
Дозвольте мені надати короткий вступ. Адам Бек заснував компанію Blockstream. У цій компанії є багато продуктів, таких як платформа розробки бічного ланцюжка elements. Вони також мають продукти green wallet, справжні пули для майнінгу та фінансові продукти, пов'язані з пулами майнінгу. Фінансові продукти тощо;
Liquid - це L2, розроблений за допомогою платформи elements, а sideswap - це проект на Liquid.
Збереження безпеки офлайн-даних забезпечується стороною проекту. Користувачі можуть захистити безпеку своїх активів, роблячи резервні копії даних. Звісно, якщо виникнуть проблеми з даними сторони проекту, а користувач не зробив резервну копію даних, то виникнуть проблеми з активами.
Деякі зловмисні проекти можуть вчиняти злочини, створюючи шкідливе програмне забезпечення, але механізм використання RGB може уникнути шахрайства механізму. Звичайно, RGB важко запобігти у всіх блокчейнах.
Так, використовуючи протокол Storm, дані діляться між ровесниками, але поточний розвиток запізнюється
Не може. Проектна сторона не може збирати інформацію про окремі транзакції і може збирати лише кількість завершених переказів у межах додатка (наприклад, загальні статистичні дані).
Звісно, я особисто вважаю, що якщо користувач авторизує відповідні дозволи, то програма може отримати доступ до цих даних (це буде трохи схоже на розкриття ключа на Liquid для перегляду прихованої інформації)
Так, але кожна компанія повинна дотримуватися вимог щодо цінних паперів.
1) Актив має ідентифікатор контракту та початкове значення генезису
2) Сумісний з гаманцем RGB
3) Відкритий код
Цим чином ви можете знати, чи це є активом RGB
UTXO - це шар "публічних" активів, але тільки між однаковими активами, наприклад: USDT<>USDT; у майбутньому ми зможемо досягнути "взаємодії" між різними активами, але для цього потрібен Bifrost
Це можливо, але цільовий ланцюг повинен підтримувати модель UTXO та інші доступні моделі для інтеграції з ядром RGB та хрестовими бібліотеками. На даний момент активи повинні відповідати специфікаціям моделі RGB20.
Фактично, RGB сумісний з LN, і ви можете використовувати його з будь-якою реалізацією LN, такою як вставка CLN або LND. При використанні Storm можливе підтвердження кожного зразка на LN; на L1 підтвердження та маршрутизація активів відбувається лише в разі відкриття / закриття каналу або сканування за допомогою HTLC.
Так, для цього потрібно багато бібліотек підтримки, які працюватимуть разом,
У теорії процес може бути спрощений через авторизацію. Звичайно, це лише у теорії.
Частина 4: Посилання на джерела
Тут ви можете дізнатися:
1️⃣Що таке RGB, що воно може робити, і які його переваги ( Стрибати)
2️⃣Як спробувати бібліотеку RGB, таку як командний рядок, встановлення вузлів, виклик API тощо. (Стрибок)
3️⃣Навчайтеся RGB через офіційні відео (звичайно, це важко для нерідкомовців) (Стрибок)
Масштабовані & конфіденційні смарт-контракти для Bitcoin & Lightning
У цьому документі пояснюються принципи дизайну та надаються глибокі технічні відомості про те, як побудовані та працюють системи RGB, включно з:
1️⃣Огляд та цілі проектування протоколу (Стрибок)
2️⃣Вступ до “Перевірки клієнта”, опис “Одноразових печаток” та”Визначених біткойн зобов’язань”(Стрибок)
3️⃣Пояснення “RGB Contract, Status і Operation” ( Стрибок)
4️⃣Деякий вміст «Спробуйте контракт RGB»: включаючи написання контрактів, взаємодію з контрактами, комунікацію P2P, взаємодію з гаманцями тощо. (Стрибок)
RGB Чорнопапір | RGB Чорнопапір
Повний, масштабований та конфіденційний рівень смарт-контрактів для Bitcoin та LN
Якщо ви зіткнетесь з проблемами, спочатку перевірте, чи цей офіційний документ має відповіді.
Тут ви можете дізнатися про машину Алу, що є повноцінною тьюрінговою машиною, розроблену Асоціацією LNP/BP
1️⃣Дослідження CoinEx
Короткий аналіз RGB: масштабований, конфіденційний протокол розумного контракту, побудований на Bitcoin
Блог | CoinEx - Глобальна криптовалютна біржа
2️⃣Федеріко Тенґа
Розуміння протоколу RGB
@FedericoTenga">Федеріко Тенга – Medium
@FedericoTenga">Читайте тексти Федеріко Тенга на Medium. Працюю над річами Bitcoin. Кожен день, Федеріко Тенга та тисячі інших голосів ре...
@FedericoTenga"medium.com
3️⃣Bitfinex
Як RGB може покращити Біткоін?
Як RGB може покращити біткоїн? - Блог Bitfinex
4️⃣Waterdrip Capital
Детальне пояснення протоколу RGB: знаходження нового способу створення нового другого рівня емісії біткойн-активів
5️⃣ Дизайн протоколу RGB
Місце зібрання китайських ідей про Bitcoin