Що таке порядковий напис?

Ordinals був запущений розробником Casey Rodarmor 20 січня 2023 року в основній мережі біткойн як протокол замовлення для «Satoshi». «Сатоші» — це найменша одиниця біткойна, і кожен біткойн складається з одного. Складається зі 100 мільйонів сатоші (1 btc = 10^8 sat), протокол Ordinals надає кожному сатоші унікальну ідентифікацію.

Ordinals Inscriptions — це незамінні токени (NFT), створені на основі протоколу Ordinals і містять такі дані, як зображення, текст і відео.

Порівняно з Ethereum NFT, ми можемо просто подумати, що протокол Ordinals реалізує tokenID, а напис реалізує метадані.

Як реалізувати tokenID

TokenID надає унікальний ідентифікатор для кожного NFT, що дозволяє користувачам відрізняти токени один від одного. TokenID — це те, що робить NFT справді унікальними.

Ethereum має хороші можливості програмування, що дозволяє легко реалізувати TokenID. Однак у Bitcoin подібні реалізації зазвичай вимагають використання мереж другого рівня. Такі платформи, як Counterparty і Stacks, уже реалізували NFT на основі біткойнів, але напис Ordinals має принципові відмінності від інших архітектур NFT біткойнів.

Протокол Ordinals використовує модель транзакцій UTXO Bitcoin. UTXO подібна до касової системи, на відміну від традиційної моделі, що базується на балансі рахунку.

У блокчейні біткойн усі баланси зберігаються в списку під назвою Невитрачені вихідні дані транзакцій (UTXO). Кожен UTXO містить певну кількість біткойнів, а також інформацію про його власника та інформацію про те, чи можна його витратити. Ви можете розглядати це як грошовий чек із зазначенням імені власника, який можна передати комусь іншому за підписом власника. Для конкретної адреси сума всіх її сум UTXO представляє баланс гаманця цієї адреси. Перебираючи всі UTXO, ми можемо отримати поточний баланс для кожної адреси. Додавання всіх сум UTXO дає нам загальний обіг Bitcoin.

Щоб краще зрозуміти платіжну модель у мережі біткойн, розглянемо приклад, коли А надсилає n біткойнів до Б. На діаграмі нижче показано процес, коли А надсилає 3 біткойни до Б.

1. Для користувача A спочатку потрібно визначити набір усіх UTXO, якими він володіє, тобто всі біткойни, якими користувач A може керувати;

2. A вибирає один або кілька UTXO із цього набору як вхідні дані транзакції. Сума цих вхідних даних становить m (2+0,8+0,5=3,3 BTC), що перевищує суму до сплати n (3 BTC);

3. Користувач A встановлює два виходи для транзакції, один вихід виплачується на адресу B, сума n (3 BTC), а інший вихід виплачується на власну адресу зміни A, сума mn-fee (3,3-3- 0,001). =0,299 BTC). Гаманець користувача зазвичай складається з кількох адрес. Як правило, кожна адреса використовується лише один раз, а зміна повертається на нову адресу за замовчуванням;

4. Після того, як майнер запакує транзакцію та завантажить її в ланцюг для підтвердження, B може отримати інформацію про транзакцію. Оскільки розмір блоку має верхню межу (приблизно 1 МБ), майнери віддадуть пріоритет транзакціям із високими ставками транзакцій (fee_rate=fee/size), щоб отримати найвищу комісію у відповідь.

Згідно з протоколом Ordinals, кількість «Satoshi» залежить від порядку їх видобутку, і оскільки кожен BTC «Satoshi» генерується за допомогою винагороди за майнінг, його серійний номер можна визначити за допомогою відстеження.

Припустімо, що користувач А отримує 100-110-й сатоші за допомогою майнінгу (10 сатоші зберігаються як ціле в одному UTXO з ідентифікатором adc123). Коли користувач A хоче заплатити 5 сатоші користувачеві B, він вирішує використовувати ідентифікатор abc123 як вхідні дані транзакції, з яких 5 сатоші надаються користувачеві B, а 5 сатоші повертаються користувачеві A як здача. Ці дві копії 5 «Сатоші» є одним цілим і зберігаються в двох UTXO з ідентифікаторами abc456 і abc789 відповідно. Наведений вище ідентифікатор UTXO та кількість «Satoshi» показані лише як приклади. У реальних ситуаціях мінімальна кількість надісланих «Satoshi» обмежена 546, а ідентифікатор UTXO не виражений у цій формі.

У наведеній вище транзакції шлях обігу 10 сатоші користувача А є таким:

1. Майнінг дає 10 «Сатоші», пронумеровані [100, 110). Вказує, що 100-109-й «Satoshi» зберігається в UTXO з ідентифікатором abc123, а його власником є користувач A.

2. Коли А переказує гроші, 10 «сатоші» діляться на дві частини, кожна по 5 «сатоші». Тут використовується принцип «першим прийшов, перший обслужений». Принцип полягає в тому, що порядок номерів «Satoshi» визначається відповідно до їх індексу у виведенні транзакції. Якщо припустити, що порядок виведення: спочатку користувач A, потім користувач B, тоді серійні номери решти 5 «сатоші» користувача A [100, 105), які зберігаються в UTXO з ідентифікатором abc456, і 5 “ користувача B. satoshis” Порядковий номер [105, 110) і зберігається в UTXO з ідентифікатором abc789.

Як реалізувати метадані

Метадані для порядкових написів не зберігаються в певному місці. Натомість ці метадані вбудовані в дані свідка транзакції (дані свідка, поле свідка), тому їх називають «написом», оскільки ці дані «вигравірувані» як напис на певних частинах транзакції Bitcoin. , і ці дані прикріплені до конкретних «Сатоші». Цей процес запису реалізується через Segregated Witness (SegWit) і Taproot, який включає два етапи: фіксацію та розкриття, і може вписувати будь-який вміст (наприклад, текст, зображення чи відео) у призначені «сатоші».

SegWit — це оновлення 2017 року, яке призвело до софт-форку блокчейну Bitcoin. Оновлення фактично розділяє транзакції біткойн на дві частини, додавши розділ «дані свідків», який може підтримувати довільні дані.

Segregated Witness розділяє дані транзакції та дані свідків (підпису) на окремі частини та дозволяє зберігати довільні дані в частині свідків.

Технічно реалізація Segregated Witness означає, що транзакціям більше не потрібно включати дані свідків (і вони не займатимуть 1 МБ місця, яке Bitcoin спочатку виділив для блоків). Замість цього в кінці блоку створюється додатковий окремий простір для даних свідків. Він підтримує довільну передачу даних і має знижену «вагу блоку», завдяки чому великі обсяги даних вміло зберігаються в межах розміру блоку Bitcoin, щоб уникнути необхідності хардфорку.

Taproot, реалізований у листопаді 2021 року, — це багатогранне оновлення, призначене для покращення конфіденційності, масштабованості та безпеки біткойнів. Taproot створює систему, яка спрощує зберігання довільних даних свідків і послаблює обмеження на кількість довільних даних, які можна розмістити в транзакції Bitcoin. Початкова мета цього оновлення полягає в подальшому вдосконаленні смарт-контрактів на основі біткойнів, таких як контракти з блокуванням часу, які зазвичай виражаються в даних свідків.

Порядкові номери зберігають метадані в сценарії витрат у шляху сценарію Taproot.

По-перше, завдяки тому, як зберігаються сценарії Taproot, ми можемо зберігати вміст написів у сценаріях витрат шляху сценаріїв Taproot, які майже не мають обмежень щодо вмісту, а також отримуємо знижки на дані свідків, що робить зберігання вмісту написів відносно економічним. Оскільки використовувати сценарії Taproot можна лише з уже наявних вихідних даних Taproot, написи карбуються за допомогою двоетапного процесу фіксації/розкриття. Спочатку в транзакції фіксації створюється вихід Taproot, який обіцяє сценарій із вмістом напису. Потім у транзакції розкриття транзакція ініціюється шляхом прийняття UTXO, відповідного цьому напису, як вхідних даних. У цей час відповідний зміст напису оприлюднили весь Інтернет.

Такий підхід значно скорочує споживання ресурсів. Якщо ви не використовуєте сценарій Taproot, інформація про свідка зберігається у виводі транзакції. Таким чином, до тих пір, поки цей вихід не споживається, інформація про свідків завжди зберігатиметься в наборі UTXO. Навпаки, якщо використовується P2TR, інформація про свідка не з’явиться в транзакції, згенерованій під час фази фіксації, тому вона не буде записана в набір UTXO. Лише коли цей UTXO використано, інформація про свідка з’явиться у вхідних даних транзакції під час фази розкриття. P2TR дозволяє записувати метадані в блокчейн Bitcoin, але ніколи не відображається в наборі UTXO. Оскільки підтримка/модифікація набору UTXO вимагає більше ресурсів, цей підхід може заощадити багато ресурсів.

Що таке BRC-20

Хоча назва BRC-20 дуже схожа на ERC-20 Ethereum, технічні відмінності між ними насправді значні. Статус зберігання токенів ERC-20 зберігається в ланцюжку, і мережевий консенсус можна отримати в ланцюжку, тоді як BRC-20 Просто спеціальний напис протоколу Ordinals, створений користувачем Twitter @domodata 8 березня 2023 року, який використовує порядковий номер записи даних JSON для розгортання контрактів токенів, карбування та передачі токенів. Розгорнутий json виглядає так:

{  

"p": "brc-20",//Protocol: Helps offline accounting systems identify and handle brc-20 events

"op": "deploy",//op operation: event type (Deploy, Mint, Transfer)

"tick": "ordi", //Ticker: identifier of the brc-20 token, 4 letters in length (can be emoji)

"max": "21000000",//Max supply: The maximum supply of brc-20 tokens

"lim": "1000"//Mint limit: The limit on the minting amount of brc-20 tokens each time

}

Відповідними операціями є mint і transfer, і ці два формати майже однакові. Коли op — Передача, одержувач передачі напису є одержувачем «Сатоші», що відповідає напису. Таким чином, передача BRC-20 має супроводжуватися передачею права власності на біткойн, а не просто використовуватися як комісія за обробку.

BRC-20 реалізує механізм «першим прийшов, першим обслужено». Повторне розгортання та надмірна кількість монет недійсні. Централізована організація виведе поточний баланс, який повинен мати користувач, на основі кожного OP, зареєстрованого в ланцюжку, і винесе судження щодо дійсності транзакції.

У цьому процесі написи «прикріплюються» до транзакції «Satoshi». Біткойн-майнери не оброблятимуть ці написи. З точки зору мережі, вони все ще нічим не відрізняються від інших «Сатоші». Всі вони вважаються звичайними «сатоши». «Конг» переноситься.

Проблема централізації БРЦ-20

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

Простіше кажучи, книга BRC-20 децентралізована та записана в ланцюжку біткойн, але процес розрахунків централізований. Зараз існує два веб-сайти, brc-20.io та unisat.io, які підтримують запити, пов’язані з токенами BRC-20.

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

Насправді ввечері 23 квітня UniSat запустив торгову платформу BRC-20, але через уразливості в бібліотеці коду вона зазнала великої кількості атак подвійних витрат. Адреса bc1pwturekq4w455l64ttze8j7mnhgsuaupsn99ggd0ds23js924e6ms9fxyht спочатку карбував передані Ordinals NFT і намагався перевести 5000 ORDI та 35 000 ORDI на свою адресу з повітря, а також намагався продати ordi, викарбуваний з повітря іншим користувачам. Згодом Unisat призупинив доступ до веб-сайту та провів розслідування, зрештою виявивши, що це вплинуло на 70 транзакцій.

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

Висновок

Суть порядкового напису така: у мережі Bitcoin за допомогою aTaproot Сценарій створює простий обліковий рівень для підрахунку та запису активів і даних.

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

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

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

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

Відмова від відповідальності:

1. Цю статтю передруковано з [小猪Go]. Усі авторські права належать оригінальному автору [web3朱大胆]. Якщо є заперечення щодо цього передруку, будь ласка, зв’яжіться з командою Gate Learn , і вони негайно розглянуть це.
2. Відмова від відповідальності: погляди та думки, висловлені в цій статті, належать виключно автору та не є жодною інвестиційною порадою.
3. Переклади статті на інші мови виконує команда Gate Learn. Якщо не зазначено вище, копіювання, розповсюдження або плагіат перекладених статей заборонено.