April 15

Чёрная магия Биткоина: Runes

Кэси Родамор предложил Runes в сентябре 2023, когда текстовый формат токенов BRC20 в Inscriptions достиг пиковых значений. Далее осенью он неоднократно будет достигать таких же уровней суточного количества транзакций, после начала поддержки BRC20 биржами. Это мотивирует и утвердит разработчика в своей главной цели — создании альтернатив для крайне не эффективного формата BRC20, который был сломан после поломки Ordinal Theory Super Testnet'ом. Подробнее случай рассматривался в лонгриде “Я стал Математикой, разрушителем jpeg-ов”.

https://dune.com/queries/2135473/3504842

Родамор предполагал, что если бы новый гипотетический протокол имел небольшой след в блокчейне и способствовал ответственному управлению UTXO, он мог бы служить снижению вреда по сравнению с существующими протоколами. Как минимум это подтверждается STAMPs — протоколом биткоин-тролля Mike In Space, который размещает данные в нерабочих публичных ключах мультиподписи в Legacy части блока. Майк особенно упорствовал в разработке нового протокола после дикуссий о недопустимости Inscriptions в блокчейне Биткоина.

Основные принципы разработчика Runes находились в целом в области ценностей Биткоин-максималистов, т.е. за исключением самой по себе цели — выпуска токенов на Биткоине, они отчётливо следуют негласным правилам сообщества. Туда входят:

  • Простота протокола.
  • Удобство использования. Есть ли детали реализации, которые негативно сказываются на пользовательском опыте? В частности, протоколы, зависящие от данных вне блокчейна, имеют меньший след в блокчейне, но вносят значительную сложность и требуют от пользователей либо управления собственными серверами, либо поиска и взаимодействия с существующими серверами.
  • UTXO Модель состояния. Протоколы, основанные на UTXO, лучше вписываются в Bitcoin и способствуют минимизации набора UTXO, избегая создания "мусорных" UTXO.
  • Основной токен - биткоин. Протоколы с собственным токеном, необходимым для операций, громоздки и естественно менее широко распространены.

На основе этих принципов можно выделить отличия от существующих протоколов для токенов в Bitcoin:

BRC-20 не основан на UTXO и довольно сложен, так как Ordinals theory для некоторых операций.

RGB по мнению Родамора очень сложен, зависит от внешних данных, находится в разработке долгое время без какого-либо освоения. То что мы бы назвали "проклятие RGB".

Counterparty имеет собственный токен, необходимый для некоторых операций, не основан на UTXO, и требует специальных кошельков.

Omni Layer имеет собственный токен, необходимый для некоторых операций, не основан на UTXO, требует отдельной инфраструктуры и индексации. Программы и клиенты плохо поддерживаются.

Taproot Assets сложен, зависит от оффчейн данных и предполагается что будет работать в основном в связи с сетью Молния, через провайдеров токенов.

В данном списке RGB и Taproot Assets являются близнецами и в целом разрабатывались изначально как оффчейн протоколы, поэтому сравнение с ончейн протоколом может быть некорректно.

Простые правила Runes позволяют им присутствовать в любом кошельке ценой относительно небольших доработок. Вероятно, протокол может функционировать даже если OP_RETURN будет уменьшен с 80 до 40 байт (то, что хочет видеть Биткоин-пурист Luke-Jr).

Помимо простых принципов в Runes заложены функции на перспективу дальнейших халвингов и они оставляют впечатление чёрной магии, поскольку совершенно очевидно, что вся экосистема, помимо удачно подобранных маркетинговых имён, имеет механизмы для длительного роста и расширения поддержки. Родамор сделал минималистичный протокол без DAO или собственного токена - дальнейшее применение будет иметь "расширительный" характер в зависимости от бизнесов и индивидуумов, которые решат строить что-либо на его основе.

Как работают Руны

Балансы Rune хранятся в UTXO (Unspent Transaction Output — Непотраченный выход транзакции). Это базовое понятие в Bitcoin. Каждый UTXO представляет собой часть общего предложения цифровой валюты, которая была получена, но еще не потрачена. В данном контексте каждый UTXO может хранить балансы Рун. Один UTXO может содержать различные количества и типы Рун, а также биткоины.

Транзакция Биткоина должна содержать протокольное сообщение, чтобы кошелёк начал иметь какое-либо отношение к Рунам. Если в ней присутствует выход, чей скрипт pubkey содержит OP_RETURN, за которым следует передача данных ASCII заглавной буквы R, то это будет означать, что она содержит протокольное сообщение, которое будет состоять из всех данных после первой буквы R.

OP_RETURN в целом используется многими другими протоколами. Это опкод скрипта Bitcoin, который помечает выход транзакции как недействительный для расходования, но позволяет ему переносить произвольные данные. Каждый узел Биткоина по умолчанию не хранит эти данные.

Когда Руны вводятся в транзакцию с недействительным или несоответствующим протокольным сообщением, они "сжигаются" или удаляются из обращения навсегда. Этот механизм предотвращает неправильное использование системы и помогает поддерживать целостность протокола, особенно во время обновлений или изменений в управлении Рунами в будущем.

Числа кодируются в протоколе как Varints (дословно, переменные целые числа). Они используются для экономии места в хранении данных путем кодирования целых чисел с переменным количеством байтов. Префиксные varints — это тип varints, где количество ведущих единиц в двоичном представлении указывает, сколько байтов используется для этого хранения целого числа.

Перевод: Эдикты

Руны передаются "эдиктами" и это самая простая функция протокола. Остаток рун из какой-либо транзакции или все руны, которые принадлежат UTXO, могут быть переданы на адрес сдачи кошелька по умолчанию.

Если хозяин токенов хочет передать некоторое количество рун другому владельцу, он может это сделать с небольшим количеством биткоинов, поскольку они необходимы для совершения транзакции как таковой. В этом случае в OR_RETURN записывается "Runestone" — "рунический камень", который хранит целые числа.

Эти целые числа интерпретируются как последовательность кортежей (ID, OUTPUT, AMOUNT). Если количество декодированных целых чисел не кратно трем, то протокольное сообщение считается недействительным. ID означает числовой идентификатор руны. OUTPUT — индекс выхода, куда передаются токены. AMOUNT — количество рун, которые передаются.

Второй и последующий ID кодируется как дельта от первого. Это позволяет избежать повторения полного идентификатора руны при многократном назначении одной и той же руны и немного оптимизирует хранение для больших чисел. Например, кортежи:

[(100, 1, 20), (0, 2, 10), (20, 1, 5)]

Производят следующие транзакции:

- ID 100, отправляется на выход 1, в количестве 20 рун,
- ID 100, на выход 2, 10 рун,
- ID 120, на выход 1, 5 рун.

Количество AMOUNT, равное 0, означает "все оставшиеся руны". После обработки всех кортежей, любые неназначенные руны присваиваются первому выходу, который не является OP_RETURN, если таковой имеется. В описываемой транзакции может быть до 3 разных получаетей, по количеству выходов, и один неявный — отправитель, которому останутся неизрасходованные руны, как было упомянуто в начале раздела, если адрес сдачи окажется первым.

Если транзакция содержит избыточные переводы рун, то они будут проигнорированы. Руны могут быть уничтожены, если они назначены на выход OP_RETURN, содержащий протокольное сообщение. На этом достаточно простые правила заканчиваются.

"Чеканка" и выпуск

Руны идентифицируются по ID, которые состоят из блока, в котором была выгравирована руна, и индекса гравировочной транзакции в этом блоке, представленного в текстовом виде как BLOCK:TX. Например, ID руны, отчеканенной в двадцатой транзакции пятисотого блока, будет 500:20.

Оказывается важным, что момент чеканки и выпуска - минта рун разделены. Родамор сделал это в целях противостояния фронтраннингу выпуска рун. Например в BRC20 из-за полной прозрачности протокола минтеры должны иметь доступ к майнерам, чтобы транзакции попадали в блок, минуя мемпул, иначе они могут быть "перехвачены" и выпущены с приоритетом при наличии дополнительной ценности, которую можно получить в аукционе.

После гравировки руны, среди множества адресов невозможно определить какой именно адрес произвёл руническую подпись, поскольку она "спрятана" в дереве Taproot и будет разглашена только в момент траты. Поэтому она становится известна только при последующем выпуске токенов. Однако транзакция закрепления имени должна находиться в том же выпуске что и рунический камень создания руны, иначе выпуск будет проигнорирован.

У Рун есть уникальная механика: более короткие символы будут разблокированы позднее, что позволяет избежать фронтраннига (опять) более привлекательных "имён". Изначально разблокируются все имена рун длиной тринадцать и более, вплоть до первого зарезервированного имени руны, который

AAAAAAAAAAAAAAAAAAAAAAAAAAA

Руны начинают разблокироваться в блоке 840 000, блоке, в котором активируется рунический протокол. После этого каждые 17 500 блоков непрерывно разблокируется следующая наименьшая длина имен рун.

Число 17500*12 = 210 000 является интервалом до следующего халвинга. Между блоком 840 000 и блоком 857 500 разблокируются двенадцатисимвольные имена рун, между блоком 857 500 и блоком 875 000 разблокируются одиннадцатисимвольные имена рун, и так далее, пока между блоком 1 032 500 и блоком 1 050 000 не будут разблокированы односимвольные имена рун.

Гравировки декодируется как два целых числа, SYMBOL и DECIMALS. Если остаются дополнительные целые числа, протокольное сообщение считается недействительным.

SYMBOL — это тикер токена, закодированный в base26 (т.е. буквами латинского алфавита от A до Z), читаемый человеком, аналогичный тому, который используется в "именах" сатов в Ordinals.

DECIMALS — это количество цифр после десятичной точки, которое следует использовать при отображении выпущенной руны.

Если SYMBOL еще не был назначен, он присваивается выпущенной руне, и выпущенная руна получает следующий доступный числовой ID руны, начиная с единицы. Если SYMBOL уже был назначен или является BITCOIN, BTC или XBT, новая руна не создается. Транзакции перевода с использованием ID руны 0 игнорируются, но другие переводы все еще обрабатываются, если такие имелись в транзакции.

Заключение

Здесь скорее всего не полное описание Рун, поскольку протокол имеет весьма небольшое количество подробного материала. Основой для "спецификации" является одна страница на проекте Ordinals и код кошелька ord. На Stacker.news открыта небольшая территория, которая также не пользуется популярностью и тред в котором собрано немного ссылок. Его отличие от этой статьи в том, что мы забыли привести ссылку на блог Родамора с оригинальной идеей.

Runes имеет все компоненты для хорошего хайпа: использует немного Taproot, чтобы улучшить рыночные свойства токенов; внутреннюю механику, которая может поддерживать малую долю хайпа внутри сообщества, для набора Линди-эффекта; не сложную реализацию, которая может быть добавлена во многие кошельки, если они освоили интеграцию с BitcoinDevKit; отличные названия.

Простота реализации даже позволяет создавать платёжные каналы на базе UTXO с Рунами. Вероятно, они могут быть проще чем Taproot Assets Protocol.

Поддержите проект 🔗 LN платежом 🔗

Или [email protected]

Например из @LightningTipBot в Телеграме

/send 100 [email protected]

Или начните пользоваться LN кошельком типа Valet.