RGB Protocol: смарт-контракти та токени на Bitcoin

Клієнти хочуть конфіденційні смарт-контракти, але не хочуть залишати Bitcoin або переходити на сайдчейни. RGB Protocol вирішує це завдання: state зберігається у власників, а Bitcoin гарантує консенсус. Наші інженери розробляють рішення на RGB v0.11 — від простих токенів до інтеграції з Lightning. Ми виконали 30+ проєктів, економлячи замовникам до 100 разів на транзакційних витратах.

Як працює client-side validation в RGB?

У RGB правила консенсусу виконуються не нодами мережі, а клієнтами. Продавець токена доводить покупцю історію переходу права власності від genesis контракту, надаючи ланцюжок consignments. Покупець самостійно валідує кожен перехід — без довіри третій стороні та без публікації даних у блокчейні. Це ключова відмінність від Ethereum: стан контракту ніколи не з'являється публічно.

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 вигідніший за Ethereum для приватних токенів?

RGB виправданий при hard вимогах до Bitcoin settlement та конфіденційності; стабільних токенах без складної контрактної логіки; Lightning-нативних застосунках; ідеологічній вимозі роботи в Bitcoin. Порівняно з Ethereum, RGB виграє в приватності (дані не публічні) та комісіях: для масових переказів економія сягає 100 разів за рахунок відсутності плати за публікацію state. При цьому екосистема ще формується, і ми беремо на себе всі ризики — гарантуємо підтримку 3 місяці після здачі.

Як створити RGB20 токен?

RGB20 — стандарт для fungible токенів (аналог ERC-20). Створення нового токена через rgb-cli або програмно через SDK:

use rgb_schemata::rgb20; use rgbstd::interface::rgb20::Rgb20; use rgbstd::stl::{Amount, Precision, RicardianContract}; let contract = rgb20::issue( ticker: "MYTKN", name: "My Token", precision: Precision::CentiMicro, // 8 знаків після коми issued_supply: Amount::from(1_000_000_00000000u64), seal: genesis_seal, terms: RicardianContract::new("Token Terms..."), )?; let contract_bytes = contract.to_strict_serialized::<{ u24::MAX as usize }>()?; 

Для розробки використовується RGB Core Library на Rust як основний SDK. Високорівнева обгортка RGB Std надає інтерфейси для роботи з конкретними стандартами.

RGB21 — стандарт для унікальних активів з опціональними медіа-вкладеннями. Медіафайли зберігаються off-chain, у state — лише хеш.

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, )?; 

Що входить в роботу та гарантії

Процес включає аналіз вимог, аудит безпеки, проектування схеми, розробку контрактів на Rust, інтеграцію з Lightning (опціонально), кастомізацію гаманця, деплой в testnet/mainnet, документацію та навчання команди. Ми передаємо:

• Вихідний код контрактів (Rust) з тестами
• Інструкцію з деплою та використання
• Доступ до приватного репозиторію
• 2 години навчання для ваших розробників
• Гарантійну підтримку 3 місяці

Терміни: від 3 тижнів для базового токена до 5 місяців для кастодіального сервісу з Lightning. Вартість розраховується індивідуально. Зв'яжіться з нами — оцінимо ваш проєкт безкоштовно. Замовте аудит поточного прототипу: знайдемо проблеми до продакшену.

Гаманець та зберігання state

Для роботи з RGB активами потрібен RGB-aware гаманець. Стандартний Bitcoin гаманець не бачить RGB баланси. Існуючі реалізації: Bitmask (веб/мобільний), BitLight (Lightning-first), MyCitadel (desktop від LNP/BP team). Для серверної сторони — інтеграція через RGB Node або пряме використання RGB Core.

RGB state зберігається в stash — локальна база власника. Stash містить всі отримані consignments, історію state transitions та необхідні witness дані.

let stash = RgbStash::new(stash_path, bitcoin_provider)?; let balance = stash.contract_state::<Rgb20>(contract_id)? .fungibles() .filter(|a| a.owner == my_seal) .sum(); 

Інтеграція з Lightning Network: як це працює

RGB-over-LN дозволяє проводити micropayments в RGB токенах по Lightning каналах. Платіж в USDC по Lightning за мілісекунди — без bridge-ів та wrapped токенів. Технічно: HTLC розширюється RGB state transition. При routing інвойс кодує не лише satoshi amount, а й RGB asset transfer. Routing nodes бачать лише звичайні HTLC. Реалізація: LDK з RGB розширеннями від Bitfinex (проєкт Iris).

Порівняння: RGB vs Ethereum для типових задач

Інструментальна таблиця: що використовуємо

Практичні обмеження та коли вибирати RGB

Немає public mempool visibility: RGB state не видимий нікому окрім учасників. Це плюс для приватності, але мінус — немає публічного block explorer. Верифікація працює лише при наявності повного consignment. UTXO як seal: при траті UTXO потрібно явно перенести RGB актив на новий output — забутий переказ = втрата активу. Екосистема ще формується: tooling менш зрілий, ніж Ethereum, документація неповна. Немає EVM-еквівалента: AluVM менш виразний, ніж Solidity, складний DeFi на RGB вимагає великих зусиль.

RGB вибирають при: hard вимогах до Bitcoin settlement та конфіденційності; стабільних токенах (transfer, issuance, burn); Lightning-нативних застосунках; ідеологічному виборі Bitcoin без сайдчейнів. Для DeFi, NFT маркетплейсів, DAO — Ethereum або L2 залишаються правильним вибором через зрілість.

Основна документація RGB: rgb.technology