Оригінальний автор: DaPangDun (X:@DaPangDunCrypto)
Примітка редактора: Дослідник шифрування DaPangDun опублікував статтю про X, щоб розібратися в ключових моментах про протокол RGB++ та екологію, щоб допомогти користувачам краще зрозуміти останні досягнення протокол та екології RGB++. Одейлі складається наступним чином:
Відповідь: Ізоморфне зв’язування забезпечує власний спосіб зіставлення активів рівня 1 на BTC (наразі обмежено ресурсами RGB++) з мережею рівня 2 (наразі обмежена CKB), що не досягається за допомогою мостів, так що активи «рівня 1-2 передаються» для забезпечення безпеки рівня 1 та масштабованості рівня 2.
Відповідь: Активи на першому поверсі не заблоковані, після Leap активи знаходяться на другому поверсі, а не на першому, і тільки коли Leap повертається, активи відновлюються. Ми можемо порівняти палітурку з «фарбуванням» пофарбованих монет, де стрибок до другого шару відповідає «знебарвленню», а стрибок назад до першого шару відповідає «повторному фарбуванню».
Відповідь: Коли активи RGB++ створюються на рівні 1, Рівень 2 ізоморфний тіньовому активу, а коли передається рівень 1, тіньові активи будуть передані в тій самій структурі, а активами в Рівень 2 можна буде оперувати лише тоді, коли користувач перейде до Рівень 2.
Відповідь: Насправді, причина високого споживання активів рівня 1 не повністю пов’язана з GAS. Споживання активів першого рівня = ГАЗ + CKB комісії, які займають однорідні CELL рівня 2 + інші.
Серед них: GAS – це мережеві комісії для участі користувачів, за винятком Mint, який, як правило, не дуже високий. Вартість заселення CKB може становити великий напір, наприклад, CELL займає 144 ККБ, за ціною 0,025 становить 3,6 ОД, якщо займає 300 кб, то 7,5 ОД. Інші посилаються на сервісні збори деяких платформ тощо.
Відповідь: лонг люди не мають належного розуміння RGB++ протокол і дивляться на протокол з точки зору поточного споживання.
Клас Inscription протокол ви можете постійно працювати тільки в основній мережі, тому її масштабованість дуже обмежена, а безперервне споживання дуже велике;
протокол RGB++ коштує дорого лише тоді, коли ви граєте в основній мережі, але його суть полягає в тому, що ви можете перейти на рівень 2 і грати на ckb, на даний момент газ в основному незначний, його масштабованість обмежена лише мережею ckb, а безперервне споживання є лише у двох процесах стрибка та стрибка.
В: Оскільки інфра на другому поверсі зараз дуже слабка, на першому поверсі вже є ринок, його більше одного, а другого рівня ще немає, то на другому поверсі можна грати тільки в «трансфер», тому я пропоную, щоб CKB проектна сторона і спільнота розвивали інфраструктуру якомога швидше; звичайно, тут я з нетерпінням чекаю розвитку інфраструктури на основі смартконтракти можливостей, наприклад, якщо вона просто імітує P2P першого рівня Ринок, я не думаю, що він досить привабливий, і це не відображає переваги, але було б цікаво розробити AMM/DEX на основі моделі клітини.
Відповідь: Цілком можливо розповсюджувати без використання централізованого способу, але це вимагає від користувачів самостійної побудови цього процесу відображення рівня 2, включаючи зрощування транзакцій, випуск та трансляцію транзакцій, а також потрібно підготувати CKB для завершення таких операцій, що в принципі неможливо для звичайних людей, тому платформа запуску обробляє такий процес у фоновому режимі. Однак я розумію, що в конкретному скриптовому співтоваристві є люди, які цим займаються, і Децентралізація дистрибутив буде реалізований в майбутньому, і буде простіше, якщо це буде дистрибутив рівня 2.
Причину можна послатися на цю публікацію: cryptowizard/status/1780112123567428060 …
A: Моє особисте припущення полягає в тому, що команда Cipher в основному відповідає за підтримку роботи, покращення та оновлення протокол, тоді як спільнота або інші команди розробляють власні інфраструктурні проєкти на основі RGB++ протокол, з одного боку, це для того, щоб впустити більше лонг розробників, а з іншого боку, вони можуть швидко сприяти розвитку екосистеми лонг лінії. Розробники приходять, тому що їхній проект, швидше за все, досягне успіху в цій екосистемі, і якщо вони бичачий в цій екосистемі, успіх місця означає можливий «успіх» у майбутньому.
З точки зору девелопменту, це повинен бути перший і другий поверхи йдуть рука об руку, тобто перший і другий поверхи екологічного проекту повинні бути зроблені, перший шар - це перша сходинка, а другий шар - друга сходинка (логічний взаємозв’язок в цьому не обов’язково, але це простіше зрозуміти), щоб перший і другий шари INFRA поступово вдосконалювалися в цьому процесі.
Відповідь: Проблема механізму протокол, після розгортання протокол він вимагає 6 блоків підтвердження безпеки, тому потрібен час на очікування.
В: Я думаю, що це питання вибору. ++ – це Відкритий вихідний код протокол, будь-хто може зробити стартовий майданчик на основі протокол, позиціонування Huehub може полягати в тому, щоб забезпечити такий функціональний модуль, як інфраструктура під екосистемою, тому вимоги аудиту немає; У той же час, аудит також певною мірою є питанням відповідальності, цей шматок поки що може не захотіти чіпати, адже платформа не має можливості нічого гарантувати. Звичайно, я розумію, що люди не хочуть мати занадто лонг активи, які не мають ефекту багатства, але нам, можливо, доведеться подумати про це з точки зору та позиціонування Huehub.
Відповідь: Насправді офіційна рекомендація була спеціально введена, і наступні моменти можна узагальнити.
Для:
Відповідь: Я особисто не дуже добре вмію інвестувати, я завжди наголошував, що мої вторинні здібності досить слабкі, тому я, як правило, шукатиму дуже ранні можливості з певним ступенем впевненості та братиму в них участь, щодо конкретної мети та інвестицій, які ви можете віднести до прагнення
@0x твіт CryptoWizard
Наостанок кілька слів про мої особисті думки:
Для нових протоколів завжди будуть проблеми того чи іншого роду, особливо коли ранній накладений INFRA відносно слабкий, тому я сподіваюся, що всі намагатимуться бути «толерантними», мати проблеми та проблеми зі зворотним зв’язком, менше злитися; Насправді швидкість розробки цих команд вже дуже швидка, а розробка за моделлю UTXO складна, та й ставлення команд, з якими я стикався досі, непогане. Звичайно, з точки зору звичайних користувачів, я сподіваюся, що ці команди зможуть мати ширшу картину та працювати разом з користувачами, щоб досягти безпрограшної ситуації.