Глибоке розуміння механізмів основного проектування та обмежень протоколу Runes

1. Runes(符文)огляд

Протягом минулого року найпомітнішою гарячою темою у сфері web3 безсумнівно стала вибухова популярність екосистеми铭文. Її походження можна відстежити до протоколу Ordinals, який надає унікальний номер кожному сатоші на біткоїні. Основний розробник Ordinals casey ще в вересні минулого року подав базовий код протоколу Runes, але він ніколи не був офіційно запущений. Це призвело до того, що деякі проекти заздалегідь форкнули цей код, випустивши такі протоколи, як RunesAlpha. Незважаючи на суперечки, всього за кілька місяців зростання ринкової вартості на сотні мільйонів доларів також продемонструвало величезний потенціал протоколу Runes.

Офіційна версія протоколу Runes очікується близько 20 квітня 2024 року на основній мережі Bitcoin. Це означає, що сторона проекту, постачальники гаманців та платформи для торгівлі NFT/FT зіткнуться з серйозним викликом: як без тестової мережі безпосередньо адаптуватися до основної мережі.

Ця стаття систематично розгляне еволюцію базових полів проекту Runes, допомагаючи читачам зрозуміти відмінності між Runes та протоколами FT, такими як Brc20, Arc20, щоб раціонально оцінити та взяти участь.

2. Спосіб запису даних на ланцюгу біткоїнів

На біткоїні є два основні способи прикріплення офлайн-даних до ланцюга: гравірування та етикетування.

2.1 Основні принципи травлення

Runes використовує техніку гравірування, що є методом безпосереднього запису інформації на блокчейн. Конкретно, це запис даних у поле op-return невитрачених виходів транзакцій Bitcoin (UTXO). Ця функція з'явилася в 2014 році в версії 0.9 клієнта Bitcoin Core. OP_RETURN створює перевірний, але не витратний вихід, що дозволяє зберігати дані на блокчейні.

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

2.2 Основні принципи гравіювання

Ordinals/brc20 та інші протоколи вбудовують метадані в свідчення транзакцій. Цей процес реалізується через ізольоване свідчення та "оплату Taproot" (P2TR), включаючи два етапи: подання та розкриття, що вимагає виконання двох транзакцій.

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

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

2.3 Порівняння двох варіантів даних для запису в блокчейн

Етчинг:

• Переваги: проста і зрозуміла логіка, низькі витрати на торгівлю, не займає пам'ять пулу повних вузлів.
• Недоліки: обмеження довжини в 80 байтів, необхідно сильно стиснути кодування даних.

Гравірування:

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

3. Аналіз базового дизайну Runes

3.1 Руни 0.11 версія

Ранні поля протоколу Runes поділяються на три частини: edicts (інформація про передачу активів), etching (інформація про розгортання активів) та burn (знищення).

Коли інформація в op_Return декодується у правильному форматі edicts, поза ланцюговий解析器 розраховує переміщення активів користувача, поле output вказує на ціль переміщення.

Вміст ескізу визначає основну інформацію про розгортання активів. Основна відмінність від ERC721 полягає в тому, що поля limit та term обмежують кількість карбування та діапазон, в якому це можна зробити. Це відображає фундаментальні відмінності між проектами з написами, рунами та випуском активів за допомогою смарт-контрактів Ethereum. Через відсутність перевірки смарт-контрактів в мережі, протокол написів єдине визначає спосіб випуску активів та участі користувачів у карбуванні, щоб забезпечити справедливий запуск.

3.2 Руни 0.18 версія

Остання версія полів Runes протоколу ділиться на чотири аспекти:

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

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

3. гравірування: спосіб розгортання активів зазнав істотних змін. Основні зміни включають:

   • ID активів змінено на рядковий формат для економії коду.
   • поле terms вводить параметри height і offset, що дозволяє емітенту вказати точку початку та закінчення карбування.
   • параметр cap контролює загальну кількість випусків.
   • Введення правил для звільнення довжини імені, контроль за дефіцитними ресурсами.
   • Використання технології гравірування (commit та reveal) для розгортання, забезпечуючи захист приватності.

4. turbo: нове поле, зарезервоване для майбутніх змін протоколу.

4. Оцінка нового протоколу Runes

Переваги:

• Відповідає потребам ринку, вирішуючи проблему панування неякісних активів в екосистемі написів.
• Вбудований протокол Ordinals, має готову базу користувачів.
• Як FT протокол, він компенсує недоліки Ordinals в аспектах роботи на ринку.
• Використання op_Return для запису даних в блокчейні, що забезпечує гнучкість бухгалтерського обліку та високу безпеку.

Недоліки:

• Існують виклики на ринку, напружений графік розробки може вплинути на початковий розвиток екосистеми.
• Складні правила, проблема з довжиною назв активів може збільшити ризик фішингу для користувачів.
• Є сумніви щодо сумісності в майбутньому, порівняно з іншими протоколами, розгортання в L2 або BVM виглядає дещо запізнілим.