Останнє відкриття: транзакції BRC-20 не застосовуються до моделі мітки BTC-UTXO

Виготовлено｜Okey Cloud Chain Research Institute

Автор｜****Джейсон Цзян

У світі Web3 дані, створені діяльністю в ланцюжку, безпосередньо відповідають потоку цінностей, і більше Альфа-версії можна виявити, опанувавши дані в ланцюжку. У поєднанні з частими ризиками на ринку шифрування в останні роки окремі та інституційні користувачі стають більш чутливими до даних у мережі. Дані в мережі стали незамінним «точним інструментом» для проникнення в зашифрований світ. Однак, зважаючи на транзакції BRC20, які нещодавно були в центрі уваги, коли ми проаналізували їхні адресні теги, ми виявили, що попередня модель BTC-UTXO, здається, не була повністю застосовна. Де проблема? Як це вирішити?

Трансакція BRC20 з PSBT

Перш ніж аналізувати проблему, ми повинні спочатку зрозуміти основну ситуацію BRC20. У січні 2023 року Кейсі Родармор, основний учасник біткойнів, запропонував «Теорію порядкових номерів», яка дозволяє користувачам записувати довільні файли (зображення, тексти, відео тощо, розмір яких не перевищує 4 МБ) на найменшій одиниці біткойна «Сатоші». Згодом анонімний аналітик @domodata створив стандарт токенів BRC20 на основі протоколу Ordinals. Це експериментальний стандарт токенів, який дозволяє будь-кому випускати токени в мережі Bitcoin.

Протокол Ordinals і стандарт BRC20 створили новий варіант використання екосистеми біткойн, окрім передачі вартості, надаючи їй ще одну привабливу логіку оповіді після халвінгу. Будучи найстарішою екологією блокчейну, біткойн сповнений нескінченної життєвої сили, і токени BRC20 також стануть треком, який привернув широку увагу в першій половині 2023 року: станом на 29 червня 2023 року налічується більше 6000 токенів, пов’язаних з BRC20. Ринкова капіталізація перевищує 600 мільйонів доларів.

Однак, на відміну від Ethereum ERC20, який може випускати та передавати токени одразу після розгортання смарт-контрактів, BRC20 — це не токен у справжньому розумінні, а «Satoshi», який записує певний текст, тому для розуміння статусу BRC20 потрібен окремий індексатор. жетони або баланс. У той же час BRC20 використовує пакет даних JSON у сценарії відкритого ключа як носій, і розгортання пов’язаних контрактів токенів, а також кастинг і передача токенів потребують використання протоколу Ordinals для встановлення напису в даних JSON формат досягнення.

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

Так званий PSBT — це стандарт, запропонований основним розробником BTC Ендрю Чоу для покращення зручності непідписаних транзакцій. Він може створити неповністю підписану транзакцію та деякі інші дані для сприяння передачі непідписаних транзакцій, сприяння переносимості непідписаних транзакцій і полегшення для кількох сторін використання однієї транзакції в різний час і в різних випадках (програмні або апаратні гаманці Підпишіть угоду. У транзакції з кількома підписами Творцю потрібно лише спочатку створити PSBT, щоб ідентифікувати UTXO, який буде використано, і вихід для отримання UTXO, а потім скопіювати PSBT у програму, яку можна підписати, та об’єднати кілька PSBT в один PSBT через Combiner. Для кожного учасника повна транзакція вважається завершеною після того, як усі сторони заповнять свої підписи.

Коротше кажучи, PSBT дозволяє користувачам підписувати лише частину введених даних, щоб допомогти токенам BRC20 здійснювати надійні транзакції без смарт-контрактів. Ринки, включаючи UniSat та інші Ordinals, використовують технологію PSBT, щоб дозволити покупцям і продавцям здійснювати транзакції без довіри та без зберігання.

**Чому транзакція BRC20 особлива? **

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

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

Візьмемо як приклад конкретну транзакцію з токеном BRC20. Зараз поширені транзакції BRC20 включають три основні типи: розгортання контракту токенів (Deploy), карбування (Mint) і передача (Transfer).

(1) У процесі розгортання та монетизації передача маркера не має адреси відправника, а лише адресу одержувача. Для транзакції передачі BTC існує щонайбільше одна адреса входу та виходу, тому модель, заснована на принцип загальних витрат не можна використовувати для розширення етикетки.

(транзакція розгортання ordi - передача маркера)

(трансакція розгортання ordi - передача BTC)

(2) Під час процесу передачі токенів BRC20 зазвичай існує кілька вхідних адрес. Ми можемо ідентифікувати адреси покупця та продавця цієї транзакції, перевіривши передачу маркера транзакції. Наприклад, у транзакції передачі ordi нижче (у якій відправник маркера (bc1p…hdjn) є продавцем транзакції, а отримувач маркера (bc1p…wftk) є покупцем транзакції.

Однак у вхідних даних транзакції передачі BTC буде кілька адрес, включаючи адресу продавця, адресу покупця та адресу підозрюваної сторонньої платформи:

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

Підсумовуючи, особливість транзакцій BRC20 в основному відображається в тому, що в процесі розгортання та монетизації з’являтиметься щонайбільше одна вхідна адреса, що не може відповідати передумовам принципу «Загальних витрат». У процесі передачі, оскільки вхідна адреса може мати кілька ролей, якщо модель UTXO на основі принципу «загальних витрат» використовується для розширення мітки адреси транзакції, покупець, продавець і стороння платформа можуть бути Це призведе до помилок у мітках, які введуть в оману інші організації щодо оцінки ринку BRC20 і навіть вплинуть на загальну точність і достовірність міток адрес Bitcoin.

**Як усунути вплив BRC20 на модель тегів ****UTXO? **

Щоб усунути негативний вплив транзакцій BRC-20, у процесі розширення моделі тегів BTC-UTXO ми можемо вибрати ідентифікацію та усунення пов’язаних транзакцій за допомогою спеціального механізму перевірки, щоб забезпечити точність усього тегу BTC-UTXO. бібліотека. У той же час, враховуючи вплив мультипідписів на модель розширення міток BTC-UTXO на основі принципу «Загальних витрат», нам також потрібно проаналізувати вхідні та вихідні сценарії пов’язаних транзакцій для фільтрації адрес із кількома підписами, тому щодо теоретичної підтримки міток UTXO. Розширення не впливають.

Серед них ідентифікація мультипідпису полягає в основному шляхом перевірки того, чи містить сценарій блокування кілька відкритих ключів і відповідні умови підпису. Сценарії блокування Multisig зазвичай містять такі коди операцій, як “OP_CHECKMULTISIG” або “OP_CHECKMULTISIGVERIFY”, і вимагають кількох підписів, щоб розблокувати кошти. Якщо у вихідному сценарії знайдено кілька відкритих ключів і відповідні умови підпису, то вихід є виводом із кількома підписами. Подібним чином, якщо вхідний сценарій містить кілька підписів, тоді вхід є введенням із кількома підписами.

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

Візьмемо для прикладу сценарій невідокремленої транзакції-свідка Pay-to-Public-Key-Hash (P2PKH). Це один з найпоширеніших типів транзакцій Bitcoin. У транзакції P2PKH відправник повинен надати хеш відкритого ключа одержувача як вихідний сценарій транзакції. Одержувач повинен надати закритий ключ, який відповідає цьому відкритому ключу, щоб розблокувати вихід. При аналізі П2ПКХ дотримуються основні правила:

Вхідний сценарій: містить інформацію про підпис і відкритий ключ; .getChunks().size() == 2;

Вихідний сценарій: OP_DUP + OP_HASH160 + pubkeyHash + OP_EQUALVERIFY + OP_CHECKSIG; визначте, чи починається він на OP_DUP і закінчується на OP_CHECKSIG.

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

Введіть скрипт: EMPTY

свідок: підпис + pubkey; під час оцінювання спочатку дізнайтеся, чи є введення ПУСТИМ, а потім оцініть, що svjedok.getPushCount() == 2

Вихідний сценарій: 0 + 20 байт програми-свідка; під час оцінки спочатку визначте, чи починається вона з 0, а потім визначте, чи довжина програми-свідка становить 20 байт. (Примітка: довжина програми-свідка у виводі P2WPKH вказана як 20 байт.)

Окрім ідентифікації адрес із кількома підписами на основі характеристик сценарію введення та виведення різних транзакцій, ми також можемо фільтрувати транзакції BRC20 на основі відповідних характеристик. Згідно з дослідженнями, транзакції BRC20 завершуються у формі офлайн-підписів за допомогою технології PSBT, а ізольований тип свідка — це напівпідпис, що закінчується на 83 у Witness.

Як ця транзакція:

(

Адреса:bc1pd6pd4pdzx2an8w8pg8dlst8329ck8t8a6ehqqatglfstqmf3f9yss9yz7y

Winess：[“1b003b4099402cde95be79ab7f4b488c74058c0f620cf4cbeb37a90ca871c4a499334a1262f24fdbe484d7511a54a04aa0d693b02159b603021942cb 74f 55e9d83”]

У Witness є напівпідпис, який закінчується на 83, тому його слід розглядати як транзакцію, пов’язану з BRC20.

Після ідентифікації різних адрес із кількома підписами та BRC20 ми можемо усунути адреси з кількома підписами та транзакції BRC20 відповідно до певних правил, щоб забезпечити здійсненність і надійність моделі розширення мітки BTC-UTXO. Основна ідея показана на малюнку нижче:

Варто зазначити, що більшість провідних світових постачальників послуг даних у ланцюжку зараз враховують вплив мультипідписів при розширенні тегів UTXO, але жодна інша організація не звернула уваги на те, що транзакції BRC20 можуть призвести до помилок тегів UTXO. . **

Подолання інформаційної прогалини** Шукаємо підвищення цінності у масивних ланцюжкових даних**

Світ Web3 незнайомий і таємничий для більшості людей, і найважливішим інструментом для розуміння світу Web3 є тег on-chain. Таким чином, здатність розпізнавання тегів стала основним показником для оцінки конкурентоспроможності аналітиків даних у мережі. Але коли ми справді обираємо постачальника послуг даних у ланцюжку, ми повинні звертати увагу не лише на кількість тегів у ланцюжку, а й на якість тегів: чи точні теги? Чи вчасні оновлення? …неправильний ярлик іноді може мати набагато більший негативний вплив, ніж його відсутність. На основі накопичених раніше можливостей технології міток і глибокого розуміння ринку BRC20 команда Okey Cloud Chain виявила та запропонувала вплив транзакцій BRC20 на модель міток UTXO. Мета полягає в тому, щоб привернути увагу ринку та підвищити довіру до біткойнів. адресні ярлики Якість і зручність використання ланцюжка роблять етикетку кращою.

На додаток до аналізу етикеток, хоча глобальний ринок мережевих послуг передачі даних має величезний потенціал розвитку щонайменше в 10 мільярдів доларів, він також потребує постійних інновацій для покращення якості продуктів і послуг. ** Постачальникам послуг даних у ланцюжку неможливо отримувати прибуток шляхом прямого продажу даних і інформації в реальному часі, як традиційні постачальники послуг фінансових даних, такі як Reuters і Bloomberg Хороші технологічні інновації та інновації в сфері послуг привертають увагу користувачів. Лише тоді, коли він ґрунтується на даних у ланцюжку та ефективно поєднується з інформацією поза ланцюгом, реалізує органічне поєднання віртуальної та реальності, а також має гострий аналіз ринку та можливості аналізу даних, послуги аналізу даних у ланцюзі можуть адаптуватися до інновацій шифрування та Розвиток ринку Web3.