Эта статья предназначена только для технического обмена и не представляет собой каких-либо инвестиционных рекомендаций.
Будет ли у BTC собственный смарт-контракт?
В недавней экосистеме Биткойн Fractal BTC наконец запустил основную сеть в сентябре после прохождения нескольких тестовых сетей. Основной особенностью Fractal является возможность иметь «умные контракты», и почти одновременно с запуском основной сети был запущен новый протокол токенов CAT 20. Какими техническими возможностями обладает CAT 20? Чему мы можем научиться?
Фрактальный биткойн
Прежде чем понять CAT 20, нам нужно кратко понять Fractal Bitcoin. Их отношения аналогичны ERC 20 и ETH. Протокол CAT 20 развернут на Fractal Bitcoin.
Fractal Bitcoin, также известный как Fractal Bitcoin, представляет собой сеть «второго уровня», полностью совместимую с BTC. По сравнению с BTC время подтверждения блока меньше и занимает всего 1 минуту. Его основной принцип прост, как следует из названия: создание нескольких копий сети BTC. Каждая цепочка будет обрабатывать транзакции. Чем больше узлов может обрабатывать транзакции, тем быстрее она будет работать. Однако конкретные детали, например, как взаимодействуют разные сети, еще не ясны, и нет соответствующих официальных технических документов для справки.
Если только транзакция цепочки второго уровня будет быстрее, похоже, волнения не будет. Однако активация OP_CAT во Fractal, от которой BTC давно отказалась по соображениям безопасности, подняла возможности Fractal Bitcoin на более высокий уровень. Некоторые говорят, что OP_CAT может позволить BTC иметь возможности смарт-контрактов. Кстати, есть простор для фантазии.
Теперь кто-то внедрил протокол, подобный ERC 20, в Fractal Bitcoin.
О том, почему от OP_CAT отказались и почему его можно использовать во Fractal Bitcoin, мы поговорим об этом позже. Здесь мы сосредоточимся на CAT 20.
Протокол CAT. Дополнительную информацию см. в официальном документе: Введение | Протокол CAT (https://catprotocol.org/).
И репозиторий GitHub: GitHub — CATProtocol/cat-token-box: монорепозиторий для пакетов, реализующих протокол CAT (https://github.com/CATProtocol/cat-token-box).
Благодаря базовой поддержке OP_CAT вскоре будет доступен соответствующий протокол CAT Protocol. В настоящее время фактически работает протокол CAT 20, и на Unisat добавлена соответствующая панель: https://explorer.unisat.io/fractal-mainnet/cat20.
Каждый должен иметь возможность отреагировать, когда увидит название CAT 20. Оно должно быть больше похоже на ERC 20. По сравнению со зрелым протоколом ERC 20, развертывание токена очень удобно для всех. Как CAT 20 реализует жизненный цикл, аналогичный ERC 20?
Развертывать
Перед развертыванием пользователям необходимо указать адрес своего кошелька и основную информацию о токене. Основная информация о токене аналогична информации ERC 20:
Будут некоторые различия. CAT 20 может устанавливать лимиты предварительного майнинга и количества для каждого монетного двора. Конечно, ERC 20 также может достичь этих возможностей за счет контрактных возможностей.
На этапе развертывания будут инициированы две транзакции, которые можно рассматривать как две фазы: «фиксация» и «раскрытие». Цитируя официальную схему, этапы развертывания следующие:
На этапе «фиксации» основная информация о токене будет записана в выходной скрипт транзакции, например имя, символ и т. д. токена. Хэш-идентификатор транзакции, инициированной на этапе «фиксации», будет использоваться в качестве символа токена для различения других токенов.
Вы можете видеть, что utxo этой транзакции «bc 1 pucq...ashx» соответствует фиксации. Затем остаются две транзакции, указывающие на «bc 1 pszp...rehc 4». Первая используется для оплаты газа за следующий этап «раскрытия», а вторая — для изменения.
На этапе «раскрытия» вы можете видеть, что есть два входа utxo, соответствующие первым двум выходам предыдущего этапа фиксации. Эта транзакция сначала выведет OP_RETURN, в котором будет сохранен хеш исходного состояния CAT 20. Затем будет выведен 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, который также является характеристикой адреса P 2 TR.
2, минтер уксо
В процессе раскрытия мы используем разные utxo в качестве входных данных, но на самом деле ключ шифрования тот же, который является закрытым ключом развертывателя. Но на этапе минтера каждый может использовать эти utxo в качестве входных данных. Как это делается?
Я предполагаю, что эта часть — это упомянутая ранее способность OP_CAT, то есть способность смарт-контрактов. Каждый минтер — это смарт-контракт. Однако исходный код этой части в настоящее время не обнародован, и конкретная реализация пока не известна.
Статус транзакции (V2)
В минтере состояние также сохраняется. Это состояние существует в двух местах: одно находится в OP_RETURN вывода транзакции, а другое хранится в смарт-контракте, который представляет собой упомянутые выше Minter и токен.
В OP_RETURN хранится хэш текущего статуса вывода транзакции, а оставшееся время монетного двора токена хранится в контракте. После каждого монетного двора количество монет вновь сгенерированного Минтера будет равно оставшемуся количеству монетных дворов, разделенному на два. Представлено схемой:
В конце игры оставшееся количество всех Minter равно 0.
Возвращаясь к исходной картине, помимо того, что Minter является смарт-контрактом, сгенерированный токен также является смарт-контрактом CAT 20. CAT 20 имеет два основных состояния: количество и адрес владельца токена. Вы можете видеть, что в отличие от предыдущего BRC 20 или надписи, ваш CAT 20 не находится в UTXO вашего адреса.
Передача
При передаче количество входных и выходных токенов в транзакции должно быть согласованным. Конечно, в одной транзакции может быть несколько разных токенов, если входные и выходные номера разных токенов согласованы.
Гореть
Если вы хотите сжечь Токен, вам нужно всего лишь перенести Токен на обычный адрес.
Подвести итог
Видно, что все операции создаются самими пользователями, что очень гибко, поэтому в контрактной части необходимо выполнить много логики проверки. Некоторые из обнаруженных до сих пор уязвимостей также связаны с небрежностью в логике проверки.
Такая конструкция может иметь некоторые преимущества:
Если вы хотите узнать статус хранения всех токенов, вам нужно только проверить utxo токена, и нет необходимости продолжать поиск.
Если вы хотите проверить текущую ситуацию с монетным двором, вы можете выполнить поиск транзакций с помощью cat в OP_RETURN.
ЗАН здесь, чтобы набрать воду без порога!
Совет: вы можете получать бесплатный токен тестовой сети в размере 0,01 ETH каждые 24 часа, чтобы помочь вам испытать и протестировать проекты Web3 в экосистеме Ethereum. Нажмите, чтобы получить его сейчас: https://zan.top/faucet?chInfo=ch_WZ.
Скоро будет поддерживаться больше публичных сетей~
Эта статья написана Yeezo (аккаунт X @GaoYeezo 75065) из команды ZAN (аккаунт X @zan_team)