Разработка решений на RGB Protocol (Bitcoin)
RGB — это протокол для смарт-контрактов и токенов поверх Bitcoin и Lightning Network, разработанный LNP/BP Standards Association. В отличие от Ethereum, где контракты и их состояние хранятся публично в блокчейне, RGB хранит состояние контрактов off-chain у владельцев активов. Bitcoin используется исключительно как anchor для commitment-ов: хеш состояния прячется в транзакцию через OP_RETURN или taproot output. Это принципиально другая модель — privacy-preserving, scalable, но требующая от разработчика понимания client-side validation.
Client-side validation: ключевая концепция
В RGB правила консенсуса выполняются не нодами сети, а клиентами. Продавец токена доказывает покупателю историю перехода права собственности от genesis контракта, предоставляя chain of consignments. Покупатель самостоятельно валидирует каждый переход по правилам контракта — без доверия третьей стороне и без публикации данных в блокчейне.
Alice → Bob (передача RGB актива):
1. Bob генерирует UTXO "seal" (Bitcoin UTXO, куда привяжется RGB право)
2. Alice создаёт state transition: "перевести N токенов на seal Боба"
3. Alice создаёт Bitcoin tx, содержащий commitment к state transition
4. Alice передаёт Bob'у consignment: state transition + историю до genesis
5. Bob валидирует: проверяет каждый переход, anchoring в Bitcoin
6. Bob подтверждает получение
Ключевой момент: содержимое state transition (сколько токенов, кому) никогда не появляется публично. В Bitcoin блокчейне — только 32-байтный хеш commitment. Внешний наблюдатель видит Bitcoin транзакцию, но не знает, что она содержит RGB transfer.
RGB Protocol v0.11: текущее состояние
RGB прошёл долгий путь через нестабильные ранние версии. Текущая production-ready версия — RGB v0.11 (выпущена в 2024). Основные изменения по сравнению с v0.10:
- AluVM — новая виртуальная машина для выполнения смарт-контрактов RGB
- Strict Types — система типов с детерминированной сериализацией
- RGB Schema — декларативное описание типа контракта
- Улучшенная интеграция с Lightning (RGB-over-LN)
RGB20: fungible токены
RGB20 — стандарт для fungible токенов (аналог ERC-20). Создание нового токена через rgb-cli или программно через SDK:
use rgb_schemata::rgb20;
use rgbstd::interface::rgb20::Rgb20;
use rgbstd::stl::{Amount, Precision, RicardianContract};
// Определяем genesis контракта
let contract = rgb20::issue(
ticker: "MYTKN",
name: "My Token",
precision: Precision::CentiMicro, // 8 знаков после запятой
issued_supply: Amount::from(1_000_000_00000000u64), // 1M токенов
seal: genesis_seal, // Bitcoin UTXO куда идут все токены в genesis
terms: RicardianContract::new("Token Terms..."),
)?;
// Сериализовать контракт для публикации
let contract_bytes = contract.to_strict_serialized::<{ u24::MAX as usize }>()?;
Для разработки используется RGB Core Library на Rust как основной SDK. Высокоуровневая обёртка RGB Std предоставляет интерфейсы для работы с конкретными стандартами (RGB20, RGB21).
RGB21: NFT и коллекционные активы
RGB21 — стандарт для уникальных активов с опциональными медиа-вложениями. Особенность: медиафайлы не хранятся on-chain и не в Bitcoin — только хеш файла в state. Сам файл — у владельца или в любом хранилище (IPFS, Arweave, centralized).
use rgb_schemata::rgb21;
let nft = rgb21::issue_unique(
name: "Rare Art #1",
token_id: TokenId::from_random(),
media: Some(EmbeddedMedia {
media_type: MediaType::from("image/png"),
data: SmallBlob::try_from(image_bytes)?,
}),
seal: nft_genesis_seal,
)?;
Кошелёк и управление state
Для работы с RGB активами нужен RGB-aware кошелёк. Стандартный Bitcoin кошелёк не видит RGB балансы — он не знает о RGB протоколе.
Существующие реализации:
- Bitmask — веб/мобильный кошелёк с RGB поддержкой
- BitLight — Lightning-first RGB кошелёк
- MyCitadel — desktop кошелёк от LNP/BP team
Для серверной стороны (custodial сервис, exchange) — интеграция через RGB Node и его RPC API или прямое использование RGB Core Rust библиотеки.
Хранение state
RGB state хранится в stash — локальная база владельца. Stash содержит:
- Все полученные consignments
- История state transitions ваших активов
- Необходимые witness данные для будущих переходов
// Инициализация сташа
let stash = RgbStash::new(stash_path, bitcoin_provider)?;
// Получить баланс RGB20 токена по контракту
let balance = stash.contract_state::<Rgb20>(contract_id)?
.fungibles()
.filter(|a| a.owner == my_seal)
.sum();
RGB поверх Lightning
Одно из ключевых преимуществ RGB — нативная интеграция с Lightning. RGB-over-LN позволяет проводить micropayments в RGB токенах по Lightning каналам. Платёж в USDC по Lightning за миллисекунды — это то, что RGB-LN делает возможным без bridge-ов и wrapped токенов.
Технически: Lightning HTLC расширяется RGB state transition. При routing инвойс в BOLT-11 кодирует не только satoshi amount, но и RGB asset transfer. Routing nodes не видят RGB данные — они маршрутизируют обычные HTLC.
Реализация: LDK (Lightning Development Kit) с RGB расширениями от Bitfinex (proect Iris). Это активно разрабатываемая область, не все edge-кейсы LN совместимы с RGB в v0.11.
Практические ограничения
Нет public mempool visibility: RGB state не виден никому кроме участников. Это privacy feature, но также означает — нет публичного block explorer для RGB. Верификация работает только при наличии полного consignment.
UTXO как seal: RGB права собственности привязаны к Bitcoin UTXO. При трате UTXO нужно явно перенести RGB актив на новый output — забытый перевод RGB = потеря актива навсегда. Это требует RGB-aware кошелька, обычный Bitcoin кошелёк "потеряет" RGB токены при трате UTXO.
Экосистема ещё формируется: RGB v0.11 — стабильная версия, но инструментарий (tooling, IDE support, debugging) значительно менее зрелый чем Ethereum. Документация неполная, большинство примеров — в тестах Rust библиотек.
Нет EVM-эквивалента: RGB смарт-контракты (AluVM) — низкоуровневые и менее выразительные чем Solidity. Сложный DeFi логика на RGB требует значительно больших усилий.
Когда выбирать RGB
RGB оправдан при: hard требованиях к Bitcoin settlement и конфиденциальности; стабильных токенах без сложной контрактной логики (transfer, issuance, burn); Lightning-нативных приложениях; идеологическом требовании работы в Bitcoin без альтернативных L1.
Для большинства DeFi-приложений, NFT маркетплейсов, DAO — Ethereum или его L2 остаются правильным выбором из-за зрелости экосистемы. RGB — правильный выбор для Bitcoin-нативных финансовых инструментов.
Стек
- Rust — единственный production-ready язык для RGB (официальная библиотека)
- RGB Core + RGB Std — основные зависимости
- Bitcoin Core или Electrum Server — как Bitcoin backend
- LND/CLN с RGB патчами — для Lightning функциональности
Разработка базового RGB20 токена с выпуском, передачей и верификацией через CLI — 2–3 недели. Кастодиальный сервис с RGB wallet, API и Lightning интеграцией — 3–5 месяцев, учитывая необходимость глубокого погружения в протокол.