Runes — это минималистичный ончейн-протокол взаимозаменяемых токенов (FT) для сети Биткоина, разработанный Кейси Родармором (автор Ordinals). В отличие от «надстроек» с внешним состоянием, Runes целиком опирается на модель UTXO и сообщения в OP_RETURN, фиксируя все значимые действия (создание, выпуск, перевод) прямо в L1. Ключевая цель — «чистая» работа с UTXO без мусора, простая индексация и предсказуемые комиссии.
В Runes введены три базовых элемента:
- Runestone — «сообщение протокола» в выходе с OP_RETURN, где закодированы параметры токена и действия.
- Etching — процедура «чеканки» (создания) нового руна с зашитыми свойствами.
- Edicts — инструкции распределения/перевода руна по выходам транзакции.
За счёт этого Runes стремится быть простым, ончейн-самодостаточным и дружелюбным к индексаторам/кошелькам, оставаясь при этом совместимым с ограничениями Script и политиками мемпула.
Основы модели
Учёт в UTXO. Баланс руна «привязан» не к аккаунту, а к конкретным выходам (UTXO): один UTXO может содержать любое количество разных рун. Передача — это перераспределение количеств между выходами новой транзакции согласно *edicts*. Такой подход наследует достоинства UTXO-модели: параллелизм трат, очевидная финальность, простая проверка.
OP_RETURN как носитель протокольных данных. Транзакция считается «протокольной», если содержит OP_RETURN-выход с маркером Runes и полезной нагрузкой (*Runestone*). В ней индексатор видит: создаётся ли новый рун (*etching*), допускается ли mint (дальнейшая эмиссия), какие *edicts* выполняются и к каким выходам применяется перевод.
Минимализм формата. Поля Runes умышленно ограничены: имя, делимость, символ, условия эмиссии (премайн/минт), RuneID/привязки к высотам и список *edicts*. Простая, компактная схема облегчает индексацию и уменьшает риск расхождений у разных реализаций.
Жизненный цикл руна
Чеканка (etching). Создатель формирует транзакцию с Runestone, описывающим свойства руна:
- Имя (уникальное в протоколе, 1–28 символов, допускаются некоторые разделители-«пули» в ряде имплементаций).
- Делимость (*divisibility*) — сколько знаков «после запятой» допускается (0 означает неделимый актив).
- Символ — краткий «значок» валюты; если не задан, в ряде интерфейсов показывается общий знак (например, ¤).
- Премайн — объём, попадающий к создателю при etching (опционально).
- Условия минтинга — открытый/закрытый выпуск, лимиты по количеству минтов, кап эмиссии, окна по высотам блоков (start/end), периодичность.
Чеканка задаёт правила навсегда: изменить делимость/имя и пр. после etching нельзя. Индексатор присваивает рунам RuneID и начинает учитывать их выпуск/переводы.
Минт (mint). Если рун создан с «открытым» минтом, любой участник может выпустить дополнительное количество в рамках заданных лимитов (например, N минтов по M единиц в каждом, только в окне блоков X–Y). Минт оформляется отдельной транзакцией с Runestone, удовлетворяющей условиям.
Перевод (transfer). Передача осуществляется через *edicts* — список «кому-сколько» для конкретного руна. Важная деталь: edicts распределяют уже существующую у входов «массу» руна по выходам. Правила консервативны: сумма на выходах не может превышать доступную сумму на входах минус сожжённое/зарезервированное.
Сжигание (burn). Сокращение предложения реализуется как edict, который направляет часть количества «в никуда» (например, не присваивает ни одному выходу, либо использует специальные конвенции). Поддержка «жёсткого» burn — в компетенции конкретных реализаций/индексаторов, но в ончейн-логике это всегда выглядит как уменьшение «массы», остающейся распределённой.
Поля руна и представление количеств
Делимость и формат отображения. Делимость задаёт точность. Например, при делимости 2 количество 1234 отображают как 12.34 единицы; при делимости 0 — как 1234 неделимых единиц. Это соглашение унифицирует UX кошельков и бирж интерфейсов.
Символ. Символ — опциональный «знак валюты». Он показывается после количества (в ряде гайдов/реализаций), но не участвует в правилах учёта. Если пустой — интерфейсы подставляют общий символ.
Имя. Имена рунам уникальны: нельзя отчеканить второй рун с тем же именем. Это снижает путаницу и фишинговые риски, характерные для систем, где имена повторяются.
RuneID. Идентификатор руна кодируется детерминированно (например, на основе высоты/индекса транзакции etching) и однозначно указывает исходное событие чеканки. Для пользователя RuneID — «технический» ключ; для индексации — источник правды при коллизиях имен.
Runestone и edicts: как кодируются действия
Runestone. Это полезная нагрузка OP_RETURN-выхода с маркером протокола. Внутри — набор TLV/varint-полей, достаточный для:
* объявления etching (свойств руна и начального распределения); * разрешения/ограничения mint (окна высот, лимиты); * набора *edicts* для распределения по выходам; * опционального «указателя» (*pointer*), связывающего edicts с конкретными выходами в транзакции.
Edicts. Каждый edict описывает: какой рун, какое количество, в какой выход направить. Совокупность edicts должна соответствовать инвариантам сохранения «массы» (inputs ≥ outputs + burn). При наличии *pointer* можно компактно адресовать нужные выходы без дублирования.
Почему это важно. Единообразная структура сообщений делает индексаторы простыми: чтобы восстановить состояние, достаточно последовательно прочитать цепочку транзакций, извлекая Runestone и применяя edicts. Внешние «сервера состояния» не требуются.
Отличие от BRC-20, RGB и Taproot Assets
Против BRC-20. BRC-20 кодирует состояние через инскрипции/тексты, порождая множество «мусорных» UTXO, а также полагается на эвристику сопоставления. Runes исходит из UTXO-балансов и жёстко определённых edicts; индексация однозначна, количество UTXO не раздувается сверх необходимости.
Против RGB. RGB мощен, но сложен и опирается на офчейн-данные/клиентскую валидацию. Runes — ончеин-самодостаточен: все факты о создании и перемещении хранятся в блокчейне, что упрощает внедрение в кошельки и сервисы.
Против Taproot Assets. TA используют сложные деревья обязательств/сидкар-данные и тоже имеют офчейн-аспекты. Runes проще в индексации, но менее выразителен по части сложных активов и мостов. Выбор зависит от требований продукта: «минимализм и простота индексирования» (Runes) или «богатая внешняя модель активов» (TA).
Комиссии и «чистота» UTXO
Экономия блокового пространства. Вместо многочисленных мелких транзакций протокол заставляет аккуратно распределять массы внутри одного tx за счёт *edicts*. Один UTXO может «нести» несколько руна сразу, что уменьшает разрастание графа UTXO.
Мемпул-практики. Поскольку сообщения Runes живут в OP_RETURN, разумные лимиты и RBF/CPFP-тактика применимы так же, как для обычных платежей транзакциями UTXO. Важно избегать длинных цепочек зависимостей и следить за ancestor/descendant-ограничениями — особенно при массовых минтах.
Сборы при массовых событиях. Горячие запуски руна (public mint) способны резко нагружать мемпулы и комиссии — UX-слой (кошельки/минтеры) должен уметь выстраивать очереди, «шардировать» суммы и использовать пакетирование.
Безопасность и вектор злоупотреблений
Детерминированность состояния. Поскольку учёт на 100% ончейн, любая честная реализация индексатора приходит к одному и тому же состоянию. Это снижает риски «рассинхрона» с внешними серверами/кэшами.
Маллеабилити и строгость правил. Данные протокола неизменяемы после включения в блок; любые попытки «воспроизведения» сообщений вне контекста трат парируются простыми проверками «inputs → outputs» в edicts.
Фишинг по именам. Уникальность имён снижает, но не отменяет фишинг: похожие строки (например, с точками/пулями) возможны. Лучшие практики — показывать RuneID и источник etching в интерфейсах.
Риски гиперспекуляции. Как и любые FT, руны подвержены памп-энд-дамп динамике. Это не вопрос протокола, но важно учитывать в UX/дисклеймерах (см. нашу базовую статью Безопасность в крипте).
Экосистема и интеграции
Кошельки. Поддержка Runes сводится к: (1) чтению OP_RETURN, (2) применению правил edicts, (3) правильному конструированию трат с множеством «цветов» в одном UTXO. Хорошей практикой является пометка UTXO по «содержимому» и защита от случайного смешивания при смене адреса.
Маркетплейсы/пулы. Сервисы листинга/mint часто требуют лишь корректной индексации и удобного UX поверх стандартной транзакции. L1-простота ускоряет появление инфраструктуры вторичного рынка.
Связь с L2. Runes — L1-стандарт; мосты в L2/сайдсистемы возможны, но это отдельная дизайн-задача (см. сайдчейны, роллапсы). Для платежей малых сумм релевантна комплементарность с Lightning Network.
Лучшие практики (для разработчиков и интеграторов)
- Не дублируйте имена. Проверяйте уникальность, показывайте RuneID и tx etching.
- Следите за делимостью. Отображайте количества единообразно, скрывайте «пыль».
- Пакетируйте переводы. Один tx с несколькими edicts лучше десятка разрозненных.
- Управляйте UTXO. Не дробите без нужды, соблюдайте политики coin control.
- Поддерживайте RBF/CPFP. Это критично для массовых минтов и пиковой нагрузки.
- Защищайте UX от коллизий. Вводите предупреждения на похожие имена/символы, давайте быстрый доступ к исходному etching-tx.
Сравнение подходов
| Стандарт | Где живут данные | Сторонние сервера/клиентская валидация | Модель учёта | Особенности/риски |
|---|---|---|---|---|
| Runes | Ончейн (OP_RETURN + UTXO) | Не требуются | UTXO-балансы, edicts | Простая индексация, «чистый» UTXO, ажиотажные минты |
| BRC-20 | Ончейн инскрипции + эвристика | Необязательно, часто да | Псевдо-аккаунтная | «Мусорные» UTXO, неоднозначности, тяжёлые индексы |
| RGB | Ончейн сиды + офчейн граф | Требуются | Клиентская валидация | Мощно, но сложно и «тяжело» для UX |
| Taproot Assets | Ончейн якоря + офчейн данные | Обычно да | UTXO + деревья обязательств | Богатая модель активов, сложность интеграции |
Частые вопросы (FAQ)
Можно ли поменять делимость/имя после etching? Нет. Свойства задаются раз и навсегда, чтобы исключить путаницу и «списки совместимости».
Кто «держит» руны — адрес или UTXO? UTXO. Один выход может нести несколько разных рун одновременно.
Почему OP_RETURN, а не инскрипции? OP_RETURN прост, ограничен по размеру и чётко отделяет протокольные сообщения от трат. Это упрощает индексаторы и снижает риски путаницы.
Можно ли сделать премайн и открытую эмиссию? Да. Параметры premine/minter-rules задаются при etching. Дальше их не изменить.
Как бороться с переполнением мемпула на минтах? Пакетирование, динамические комиссии, очереди, RBF/CPFP. Кошельки должны уметь «вежливо» ретраить и не строить длинных зависимостей.
Есть ли «идеальная» альтернатива Runes? Каждый стандарт решает свою задачу. Если вам нужна ончейн-простота и UTXO-«гигиена» — Runes хорошая отправная точка. Для сложных активов/мостов смотрите Taproot Assets или решения L2.