CAT20：Токенпротокол Fractal BTC

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

BTC теж має мати свій смартконтракт?

Останнім часом у екосистемі BTC після багатьох раундів Тестова мережа, Fractal BTC нарешті запустив Основна мережа в вересні. Однією з головних особливостей Fractal є здатність до «смарт-контрактів» і майже одночасне запуску нового протоколу Токен CAT 20. Які витончені технічні рішення є в CAT 20? Що ми можемо вивчити з цього?

Фрактальний Біткоін

Перш ніж дізнатися про CAT 20, ми повинні коротко ознайомитися з Fractal Bitcoin. Їхній взаємозв'язок схожий на взаємозв'язок ERC 20 і ETH. Протокол CAT 20 розгортається на платформі Fractal Bitcoin.

Fractal Bitcoin, також відомий як фрактальний BTC, є повністю сумісною мережею "другого рівня" з BTC. Порівняно з BTC, час підтвердження Блоків є швидшим і становить лише 1 хвилину. Основний принцип досить простий - мережу BTC було репліковано кілька разів, кожен ланцюжок оброблятиме транзакції, що дозволяє більшій кількості Нод обробляти транзакції, що природно прискорює швидкість. Проте конкретні деталі, такі як спосіб зв'язку між різними ланцюжками, наразі не зовсім зрозумілі, і офіційна документація з цієї технології також відсутня.

Якщо лише торгівля на другому рівні виглядає швидше, здається, немає нічого захоплюючого. Але в Fractal вже давно використовується BTC, який був відкинутий з міркувань безпеки, Код операції OP_CAT, що дозволяє піднятися Bitcoin Fractal на новий рівень, деякі люди кажуть, що OP_CAT може надати BTC можливість смарт-контрактів, що відкриває більше можливостей для уявлення.

Зараз хтось реалізував протокол, схожий на ERC 20, на Fractal Bitcoin.

Щодо того, чому OP_CAT було відхилено, але він все ще може використовуватися в Fractal Bitcoin, ми можемо розповісти про це детальніше в майбутньому. Тут ми говоримо про CAT 20.

CAT Протокол Нижче наведена інформація є посиланням на Біла книга: Вступ | CAT Протокол ()

а також сховище GitHub: GitHub - CATProtocol/cat-token-box: Monorepo для пакетів, що реалізовують протокол CAT ()

З підтримкою OP_CAT на нижній рівень, швидко з'явився відповідний протокол - CAT Protocol. Наразі уже існує протокол CAT 20, який активно використовується, а також на Unisat з'явилася відповідна панель:

Побачивши назву CAT 20, всі, ймовірно, зможуть зрозуміти, що вона схожа на ERC 20. Порівняно з вже встановленим протоколом ERC 20, деплоймент токена став дуже зручним. Як CAT 20 забезпечує подібний життєвий цикл ERC 20.

Розгорнути

Перед розгортанням користувач повинен вказати свою ГаманецьАдреса та основну інформацію про Токен, основна інформація про Токен схожа на ERC 20:

Є кілька відмінностей. CAT 20 може налаштувати попередню розкопку та обмеження кількості монет при кожному мінті. Звичайно, ERC 20 також може реалізувати ці можливості за допомогою контракту.

На етапі розгортання будуть здійснені дві транзакції, які можна розглядати як два етапи: «commit» та «reveal». За офіційними даними, етапи розгортання виглядають наступним чином:

На сцені «зафіксувати» основна інформація про Токен буде включена в вихідний сценарій угоди, така як назва Токен, символ тощо. Хешід угоди, ініційований на етапі «зафіксувати», виступатиме як ідентифікатор цього Токен, використовуваний для відокремлення від інших Токен.

Можна побачити, що ця угода «bc 1 pucq...ashx» є utxo, яке відповідає коміту. Потім залишок два угоди, що спрямовуються на «bc 1 pszp...rehc 4», перша з яких призначена для оплати газових витрат на етапі «розкриття», а друга - решта.

На етапі «розкриття» можна побачити два входи utxo, які відповідають двом попереднім виходам на етапі фіксації. У цій угоді спочатку буде виведена операція OP_RETURN, в якій буде збережено хеш початкового стану CAT 20. Потім буде виведено Minter, який візьме участь у подальшому процесі Mint, щоб зберігати зміни стану процесу Mint.

Придивившись до всього процесу розгортання, «commit» та «reveal» дотримуються поширених кроків подання та виявлення у блокчейні, що є досить поширеним способом розгортання проектів, деякі дані проекту виявляються лише на етапі «reveal».

Монета

Спочатку ми розглянемо, як відбувається торгівля під час Mint Token.

На зазначеному вище знімку зображено особливості процесу створення Mint.

• Введення mint є мінтером, спочатку воно генерується при розгортанні.
• Кожен раз, коли мінтується, є лише одна особа, яка використовується як вхід, і будь-яка кількість осіб, які використовуються як вихід (має деякі проблеми)
• Кожен раз мінтінгу є тільки один токен (є трохи проблем)
• Порядок виводу має певні вимоги, після minter обов'язково повинен йти токен

Знаючи процес монетизації, насправді ми можемо виявити деякі спеціальні випадки, які зроблять всій процес монетизації цікавішим.

Наприклад, як вихід mint-транзакції, minter може бути 1, декілька або навіть 0. Якщо кожного разу, коли проводиться Mint, встановлюється 1, то кількість minter, яку можна використовувати в мережі, залишиться незмінною (1), це зробить Mint напівпереповненим, всім потрібно буде боротися за цього minter, щоб уникнути такої ситуації, потрібно встановити кількість minter, яку видається кожного разу, більше 1, після цього mint, кількість minter, яку можна використовувати, буде зростати.

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

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

Побудова торгівлі

Можливо, деякі друзі виявили проблему, а саме, чому можна використовувати utxo мінтера для побудови транзакції? Щоб зрозуміти це питання, потрібно проаналізувати вихідний код "контракту".

1. відкрити utxo

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

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

Можна зрозуміти, що відбувається, переглянувши вихідний код:

Тут ще є одна проблема: якщо одному Закритому ключу відповідає один Відкритий ключ, то чому згенерована Адреса commit відрізняється від нашої Адреси? Це можна побачити в початковому коді.

Це означає, що наш Закритий ключ буде налаштовуватися за допомогою ISSUE_PUBKEY, щоб змінювати Відкритий ключ, що є однією з особливостей Адреси P2TR.

2. мінтер utxo

під час процесу розкриття ми використовуємо різні utxo як вхід, але насправді секретний ключ для шифрування однаковий, тобто це приватний ключ розгортання. Але на етапі мінтингу всі можуть використовувати ці utxo як вхід, як це можливо?

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

Статус транзакції (V2)

У Minter також є стан, який зберігається. Цей стан має два місця зберігання: одне - це OP_RETURN вихідних транзакцій, інше - це смарт-контракт, який зберігається вище згаданим Minter та Токеном.

У OP_RETURN зберігається Хеш поточного стану виведення угоди, у контракті буде зберігатися залишкова кількість Мінтінга токенів. Після кожного Мінту кількість нових мінтерів буде дорівнювати залишковій кількості, яку можна мінтити, поділеній на два. Показано на графіку:

Коли все закінчено, залишилася кількість Minter 0.

Повернення до початкового малюнку, на якому Minter є смартконтрактом, а згенерований токен є також смартконтрактом, а саме CAT 20. CAT 20 має два основних стану: кількість та власник адреси TOKEN. Можна побачити, що, на відміну від BRC 20 чи напис, ваш CAT 20 не знаходиться на UTXO адресі.

Переказ

Під час переказу, кількість токенів у введенні та виведенні, які будуть використані для побудови транзакції, повинні бути однаковими. Звичайно, у одній транзакції може бути декілька різних токенів, просто кількість введення та виведення для різних токенів повинна бути однаковою.

Згорання

Щоб спалити TOKEN, вам потрібно просто перевести його на звичайну Адреса.

Загальний висновок

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

Такий дизайн може мати свої переваги:

• Якщо ви хочете знайти всі утримані токени, достатньо перевірити utxo токена, не потрібно продовжувати шукати вгору.
• Якщо ви хочете переглянути поточний стан монети, ви можете просто шукати транзакції з даними OP_RETURN, в яких є слово "cat".

ZAN бездрібний прихід води прийшов!

Порада: кожні 24 години можна отримати 0,01 ETH безкоштовного тестового токена, щоб підтримати ваш досвід і тестування проектів Web3 в екосистемі ETH, натисніть, щоб одразу отримати:

Більше публічних ланцюгів скоро підтримуватимуться ~

Цю статтю написав Yeezo (X аккаунт @GaoYeezo 75065) з ZAN Team (X аккаунт @zan_team).