Эта статья предназначена только для технического обмена и не представляет собой каких-либо рекомендаций по инвестированию.
Будет ли у BTC собственный смарт-контракт?
В недавней экосистеме Биткойн Fractal BTC наконец запустил основную сеть в сентябре после прохождения нескольких тестовых сетей. Основной особенностью Fractal является возможность иметь «умные контракты», а новый протокол токенов CAT20 был запущен почти одновременно с запуском основной сети. Какими техническими возможностями обладает CAT20? Чему мы можем научиться?
Фрактальный биткойн
Прежде чем понять CAT20, нам нужно кратко понять Fractal Bitcoin. Их отношения аналогичны ERC20 и ETH. Протокол CAT20 развернут на Fractal Bitcoin.
Fractal Bitcoin, также известный как Fractal Bitcoin, представляет собой сеть «второго уровня», полностью совместимую с BTC. По сравнению с BTC время подтверждения блока меньше и занимает всего 1 минуту. Его основной принцип прост, как следует из названия: создание нескольких копий сети BTC. Каждая цепочка будет обрабатывать транзакции. Чем больше узлов может обрабатывать транзакции, тем быстрее она будет работать. Однако конкретные детали, например, как взаимодействуют разные сети, пока не ясны, и нет соответствующих официальных технических документов для справки.
Если только транзакция цепочки второго уровня будет быстрее, похоже, нет смысла волноваться. Однако активация OP_CAT во Fractal, от которой BTC давно отказалась по соображениям безопасности, подняла возможности Fractal Bitcoin на более высокий уровень. Некоторые говорят, что OP_CAT может позволить BTC иметь возможности смарт-контрактов. Кстати, есть простор для фантазии.
Теперь кто-то внедрил протокол, подобный ERC20, в Fractal Bitcoin.
О том, почему от OP_CAT отказались и почему его можно использовать в Fractal Bitcoin, мы поговорим об этом позже. Здесь мы сосредоточимся на CAT20.
Протокол CAT
Дополнительную информацию см. в официальном документе: Введение | Протокол CAT (https://catprotocol.org/).
И репозиторий github:
GitHub - CATProtocol/cat-token-box: Монорепозиторий для пакетов, реализующих протокол CAT (https://github.com/CATProtocol/cat-token-box)
Благодаря базовой поддержке OP_CAT вскоре будет доступен соответствующий протокол CAT Protocol. В настоящее время фактически работает протокол CAT20, и на Unisat добавлена соответствующая панель: https://explorer.unisat.io/fractal-mainnet/cat20.
Каждый должен иметь возможность отреагировать, увидев название CAT20. Оно должно быть больше похоже на ERC20. По сравнению со зрелым протоколом ERC20, развертывание токена очень удобно для всех. Как CAT20 реализует жизненный цикл, аналогичный ERC20.
Развертывать
Перед развертыванием пользователям необходимо указать адрес своего кошелька и основную информацию о токене. Основная информация о токене аналогична информации ERC20:
Будут некоторые различия. CAT20 может устанавливать лимиты предварительного майнинга и количества для каждого монетного двора. Конечно, ERC20 также может достичь этих возможностей за счет контрактных возможностей.
На этапе развертывания будут инициированы две транзакции, которые можно рассматривать как две фазы: «фиксация» и «раскрытие». Цитируя официальную схему, этапы развертывания следующие:
На этапе «фиксации» основная информация о токене будет записана в выходной скрипт транзакции, например имя, символ и т. д. токена. Хэш-идентификатор транзакции, инициированной на этапе «фиксации», будет использоваться в качестве символа токена для различения других токенов.
Вы можете видеть, что utxo этой транзакции «bc1pucq...ashx» соответствует фиксации. Затем остаются две транзакции, указывающие на «bc1pszp...rehc4». Первая используется для оплаты платы за газ для следующего этапа «раскрытия», а вторая — для изменения.
На этапе «раскрытия» вы можете видеть, что есть два входа utxo, соответствующие первым двум выходам предыдущего этапа фиксации. Эта транзакция сначала выведет OP_RETURN, в котором будет сохранен хеш исходного состояния CAT20. Затем будет выведен Minter, который сыграет важную роль в последующем процессе Mint и будет использоваться для поддержания изменений состояния процесса Mint.
Оглядываясь назад на весь процесс развертывания, «фиксация» и «раскрытие» следуют за двумя этапами отправки и раскрытия, обычно используемыми в блокчейне. Это относительно распространенный способ развертывания проектов. Некоторые данные проекта находятся только в «раскрытии». этапы будут раскрыты.
Как
Когда мы впервые смотрим на Mint Token, транзакция выглядит следующим образом.
Как вы можете видеть на рисунке выше, процесс Mint имеет следующие характеристики.
Входные данные mint — это минтер, который изначально генерируется во время развертывания.
Каждый монетный двор имеет одного и только одного минтера на входе и любое количество минтеров на выходе (немного проблематично).
У каждого монетного двора есть только один жетон (немного проблематично).
Требуется порядок вывода, за minter должен следовать токен
Зная процесс Mint, мы можем обнаружить некоторые особые ситуации, которые сделают весь процесс Mint интересным.
Например, minter, как результат транзакции mint, может иметь значение 1, кратное или даже 0. Если Mint каждый раз устанавливать на 1, то количество минтеров, которые можно использовать во всей сети, останется неизменным (1), что сделает Mint перегруженным, и всем нужно будет захватить этот минтер, чтобы этого избежать. В этом случае необходимо каждый раз устанавливать количество выводимых минтеров больше 1, чтобы после монетного двора можно было использовать все больше и больше минтеров.
Однако каждый дополнительный выход минтера означает, что вам нужно платить больше utxo. По экономическим причинам все больше людей будут рады установить минтер на 0, что неизбежно приведет к дефляции минтера, что потребует от некоторых людей сделать пожертвование и заплатить. дополнительный минтер добровольно.
В версии V2 по умолчанию создаются два минтера, и статус двух минтеров будет максимально схожим.
Структурирование сделки
Некоторые друзья, возможно, обнаружили проблему, а именно: почему utxo minter можно использовать для создания транзакций? Чтобы разобраться в этой проблеме, нужно проанализировать исходный код «контракта».
1, раскрыть utxo
Сначала мы анализируем транзакцию в процессе раскрытия и обнаруживаем, что она использует выходную фиксацию предыдущей транзакции в качестве входных данных. Почему мы можем взять utxo, который не является нашим адресом, и сконструировать ввод транзакции?
Согласно здравому смыслу, закрытый ключ соответствует открытому ключу, а открытый ключ определяет адрес. При проверке правильности входного utxo обычно это определяется путем сравнения подписи с исходной транзакцией после расшифровки с помощью открытого ключа. Эта часть логики написана в биткойн-скрипте. Таким образом, мы можем хитро переписать логику скрипта. Пары открытого и закрытого ключей, записанные в скрипте, принадлежат нашему собственному адресу, так что мы можем управлять utxo двух разных адресов.
Глядя на исходный код, мы видим, что произошло:
Здесь есть еще одна проблема, то есть приватный ключ соответствует публичному ключу, так почему же сгенерированный адрес коммита отличается от нашего адреса? Здесь вы можете увидеть это из исходного кода
Другими словами, наш закрытый ключ будет корректировать открытый ключ в соответствии с ISSUE_PUBKEY, который также является характеристикой адресов P2TR.
2, минтер усо
В процессе раскрытия мы используем разные utxo в качестве входных данных, но на самом деле ключ шифрования тот же, который является закрытым ключом развертывателя. Но на этапе минтера каждый может использовать эти utxo в качестве входных данных. Как это делается?
Я предполагаю, что эта часть — это упомянутая ранее способность OP_CAT, то есть способность смарт-контрактов. Каждый минтер — это смарт-контракт. Однако исходный код этой части в настоящее время не обнародован, и конкретная реализация пока не известна.
Статус транзакции (V2)
В минтере состояние также сохраняется. Это состояние существует в двух местах: одно находится в OP_RETURN вывода транзакции, а другое хранится в смарт-контракте, который представляет собой упомянутые выше Minter и токен.
В OP_RETURN хранится хэш текущего статуса вывода транзакции, а оставшееся время монетного двора токена хранится в контракте. После каждого монетного двора количество монет вновь сгенерированного Минтера будет равно оставшемуся количеству монетных дворов, разделенному на два. Представлено схемой:
В конце игры оставшееся количество всех Minter равно 0.
Возвращаясь к исходной картине, помимо того, что Minter является смарт-контрактом, сгенерированный токен также является смарт-контрактом CAT20. CAT20 имеет два основных состояния: количество и адрес владельца токена. Вы можете видеть, что в отличие от предыдущего BRC20 или надписи, ваш CAT20 не находится на UTXO вашего адреса.
Передача
При передаче количество входных и выходных токенов в транзакции должно быть согласованным. Конечно, в одной транзакции может быть несколько разных токенов, если входные и выходные номера разных токенов согласованы.
Гореть
Если вы хотите сжечь Токен, вам нужно всего лишь перенести Токен на обычный адрес.
Подвести итог
Видно, что все операции создаются самими пользователями, что очень гибко, поэтому в контрактной части необходимо выполнить много логики проверки. Некоторые из обнаруженных до сих пор уязвимостей также связаны с небрежностью в логике проверки.
Такая конструкция может иметь некоторые преимущества:
Если вы хотите узнать статус хранения всех токенов, вам нужно только проверить utxo токена, и нет необходимости продолжать поиск.
Если вы хотите проверить текущую ситуацию с монетным двором, вы можете выполнить поиск транзакций с помощью cat в OP_RETURN.
ЗАН здесь, чтобы набрать воду без порога!
Совет: вы можете получать бесплатный токен тестовой сети в размере 0,01 ETH каждые 24 часа, чтобы помочь вам испытать и протестировать проекты Web3 в экосистеме Ethereum. Нажмите, чтобы получить его сейчас: https://zan.top/faucet?chInfo=ch_WZ.
Скоро будет поддерживаться больше публичных сетей~
Эта статья написана Yeezo (аккаунт X @GaoYeezo75065) из команды ZAN (аккаунт X @zan_team)
