Розробка рішень на 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.
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 (project 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 — стабільна версія, але інструментарій (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 тижні. Custodial сервіс з RGB wallet, API та Lightning інтеграцією — 3–5 місяців, враховуючи необхідне глибоке занурення в протокол.