BRC-20 — метапротокол, то есть правила интерпретации данных, сохранённых в Bitcoin. Его базовые операции deploy, mint и transfer создают токен, выпускают единицы и передают их. Это не дополнительные BTC и не новая часть консенсуса Bitcoin.
Автор под псевдонимом domo исследовал, можно ли создать на основе Ordinals взаимозаменяемые токены: единицы одного токена с одинаковой ролью в учёте. Исходный текст описывает эксперимент и предостерегает от восприятия его как окончательного решения. Правила BRC-20 — соглашение участников, а не изменение правил Bitcoin. [1]
Inscription — содержимое в данных witness при расходовании выхода Taproot. Для BRC-20 оно представляет собой JSON: текст с именованными полями, например p, op и tick. Узел Bitcoin проверяет транзакцию, но не исполняет этот текст как учёт токенов. Его смысл интерпретирует индексатор. [5]
Первый действительный deploy занимает тикер — обозначение токена без различия регистра букв. Он задаёт предложение max и при необходимости лимит выпуска lim и точность dec. Базовые правила допускают до 18 знаков после запятой. Помимо исходных тикеров на 4 байта, IP1 ввёл тикеры на 5 байтов, связанные с self_mint. Считаются байты UTF-8, а не буквы; эти варианты нельзя произвольно заменять друг другом. [2] [3] [6]
Сначала владелец создаёт transfer inscription с суммой amt. Она резервируется из доступного баланса, а общий баланс пока не меняется. Лишь первое перемещение этой inscription передаёт единицы получателю. Перевод самому себе снимает резервирование. Каждую transfer inscription можно использовать только раз: повторная продажа той же записи не переведёт токены снова. [1] [3]
Индексаторы должны одинаково учитывать порядок событий, лимиты и первый перевод. Владельца баланса они отслеживают по scriptPubKey — блокирующему скрипту выхода, а не только по отображаемому адресу. Реорганизация может изменить порядок и итоговый учёт. Поэтому само подтверждение транзакции Bitcoin не доказывает действительность её операции BRC-20. [3]
Базовые правила принимают тип содержимого text/plain или application/json и корректный JSON. Обязательные поля и названия операций пишутся строчными буквами; требуемые значения, включая числа, являются строками в кавычках. dec ограничивает число десятичных знаков, а uint64_max — числовой диапазон. Число без кавычек или лишняя запятая могут сделать операцию недействительной, даже если человек легко её прочитает. [3]
Если сервис сначала создаёт mint на собственный адрес, токеновый баланс может достаться ему. Последующая передача самой mint inscription не переносит этот баланс. Случайное расходование соответствующего UTXO тоже может дать неожиданный результат. Отправка inscription в качестве комиссии майнеру и уничтожение токенов подчиняются отдельным правилам; обычный перевод BTC — не универсальная инструкция для BRC-20. [1] [6]
Проверьте первый действительный deploy, max, lim, dec и при необходимости self_mint, затем проследите события в порядке блоков и транзакций. OPI позволяет сравнивать хеши событий каждого блока и накопительный хеш истории. Версия правил должна совпадать: новые программируемые модули расширяют исходную модель. Здесь объясняется её основа, а не каждое расширение. [4]
Для полной картины прочитайте эту статью вместе с Ordinals Inscriptions, Runes, UTXO, Taproot, Bitcoin Script, Fee Rate.
01Проверяют ли Full Nodes Bitcoin операции BRC-20?+
Они проверяют транзакции Bitcoin и их скрипты, но не считают балансы BRC-20. Их восстанавливает индексатор по правилам метапротокола. Поэтому одного узла Bitcoin недостаточно для проверки токенового учёта.
02BRC-20 и Runes — одно и то же?+
Нет. Базовый BRC-20 использует текстовые Ordinals Inscriptions и перевод в два шага. Runes записывает двоичные сообщения runestone в выход с OP_RETURN и иначе связывает токены с UTXO. Правила этих систем не взаимозаменяемы.