RGB Magic: клієнтські контракти на біткойн

Це редакційна стаття Федеріко Тенга, який тривалий час брав участь у проектах біткойн і мав досвід засновника стартапу, консультанта та педагога.

Термін «розумні контракти» з’явився ще до винаходу блокчейну та самого біткойна. Перша його згадка в с Стаття 1994 року Ніка Сабо, який визначив розумні контракти як «комп’ютеризований протокол транзакцій, який виконує умови контракту». Хоча за цим визначенням біткойн, завдяки своїй мові сценаріїв, підтримував смарт-контракти з самого першого блоку, цей термін був популяризований лише пізніше промоутерами Ethereum, які перекрутили оригінальне визначення як «код, який надлишково виконується всіма вузлами в глобальному консенсусі». мережа"

Хоча делегування виконання коду глобальній консенсусній мережі має переваги (наприклад, легко розгортати необов’язкові контракти, такі як популярні автоматизовані маркет-мейкери), ця конструкція має один головний недолік: відсутність масштабованості (і конфіденційності). Якщо кожен вузол у мережі повинен резервно запускати той самий код, обсяг коду, який можна фактично виконати без надмірного збільшення вартості роботи вузла (і, таким чином, збереження децентралізації), залишається дефіцитним, а це означає, що лише невелика кількість контрактів може бути виконана. виконано.

Але що, якби ми могли розробити систему, де умови контракту виконуються та підтверджуються лише залученими сторонами, а не всіма учасниками мережі? Уявімо приклад компанії, яка хоче випустити акції. Замість того, щоб публічно публікувати договір емісії в глобальній книзі та використовувати цю книгу для відстеження всіх майбутніх передач прав власності, вона могла б просто випустити акції приватно та передати покупцям право на подальшу їх передачу. Тоді право на передачу права власності може бути передано кожному новому власнику, як якщо б це було поправкою до первісного договору емісії. Таким чином, кожен власник може самостійно перевірити, що акції, які він або вона отримали, є справжніми, прочитавши оригінальний контракт і підтвердивши, що вся історія змін, які перемістили акції, відповідає правилам, викладеним у первинному контракті.

Насправді в цьому немає нічого нового, це дійсно той самий механізм, який використовувався для передачі власності до того, як державні реєстри стали популярними. У Великобританії, наприклад, до 90-х років не було обов’язково реєструвати майно, коли воно передавалося у власність. Це означає, що сьогодні понад 15% землі в Англії та Уельсі незареєстровані. Якщо ви купуєте незареєстровану нерухомість, замість того, щоб перевіряти в реєстрі, чи є продавець справжнім власником, вам доведеться підтвердити безперервний ланцюжок власності щонайменше 15 років тому (період вважається достатньо довгим, щоб припустити, що продавець має достатнє право власності на майно). При цьому ви повинні переконатися, що будь-яка передача права власності була здійснена правильно, і що будь-яка іпотека, використана для попередніх операцій, була повністю погашена. Ця модель має перевагу покращеної конфіденційності над правом власності, і вам не потрібно покладатися на ведучого публічного земельного реєстру. З іншого боку, це значно ускладнює для покупця перевірку права власності продавця.

Як можна покращити передачу незареєстрованої власності? Перш за все, зробивши це процес оцифрованим. Якщо є код, який можна запустити за допомогою комп’ютера, щоб перевірити, чи вся історія передачі права власності відповідає правилам оригінального контракту, купівля та продаж стають набагато швидшими та дешевшими.

По-друге, щоб уникнути ризику того, що продавець подвійно витратить свої активи, необхідно запровадити систему підтвердження публікації. Наприклад, ми могли б запровадити правило, згідно з яким кожна передача права власності повинна здійснюватися у заздалегідь визначеному місці відомої газети (наприклад, розмістити хеш передачі права власності у верхньому правому куті першої сторінки газети New York разів). Оскільки ви не можете розмістити хеш переказу в одному місці двічі, це запобігає спробам подвійного витрачання. Однак використання відомої газети для цієї мети має деякі недоліки:

1. Для перевірки потрібно купити багато газет. Не дуже практично.
2. Для кожного контракту потрібна окрема площа в газеті. Не дуже масштабована.
3. Редактор газети може легко цензурувати або, що ще гірше, симулювати подвійні витрати, розміщуючи випадковий хеш у вашому слоті, змушуючи будь-якого потенційного покупця вашого активу думати, що він був проданий раніше, і перешкоджаючи йому купувати його. Не дуже довірливий.

З цих причин потрібно знайти краще місце для публікації підтвердження передачі права власності. А який кращий варіант, ніж біткойн-блокчейн, уже створена надійна публічна книга з сильними стимулами підтримувати її стійкість до цензури та децентралізованість?

Якщо ми використовуємо біткойн, ми не повинні вказувати фіксоване місце в блоці, де має відбутися зобов’язання передати право власності (наприклад, у першій транзакції), тому що, як і у випадку з редактором New York Times, майнер може з цим пограти. Кращий підхід полягає в тому, щоб помістити зобов’язання в попередньо визначену транзакцію біткойн, точніше в транзакцію, яка походить від невитрачених вихідних даних транзакції (UTXO), з якими пов’язане право власності на актив, що випускається. Зв’язок між активом і біткойн-UTXO може відбуватися або в контракті, який випускає актив, або в подальшій передачі права власності, щоразу роблячи цільовий UTXO контролером переданого активу. Таким чином, ми чітко визначили, де повинно бути зобов’язання передати право власності (тобто в транзакції біткойн, що походить від конкретного UTXO). Будь-хто, хто керує біткойн-вузлом, може самостійно перевірити зобов’язання, і ні майнери, ні будь-яка інша організація не можуть піддавати цензурі або будь-яким чином перешкоджати передачі активів.

Оскільки в блокчейні біткойн ми публікуємо лише зобов’язання щодо передачі права власності, а не зміст самої передачі, продавцю потрібен спеціальний канал зв’язку, щоб надати покупцеві всі докази того, що передача права власності є дійсною. Це можна було б зробити кількома способами, потенційно навіть роздрукувавши пробні відбитки та відправивши їх разом із поштовим голубом, що, хоч і трохи непрактично, все одно виконало б роботу. Але найкращим варіантом уникнути цензури та порушень конфіденційності є встановлення прямого однорангового зашифрованого зв’язку, який порівняно з голубами також має перевагу в тому, що його легко інтегрувати з програмним забезпеченням для перевірки доказів, отриманих від контрагента.

Ця щойно описана модель для перевірених на стороні клієнта контрактів і передачі права власності – це саме те, що було реалізовано за допомогою протоколу RGB. За допомогою RGB можна створити контракт, який визначає права, призначає їх одному або кільком існуючим біткойнам UTXO і визначає, як можна передати їх право власності. Контракт можна створити, починаючи з шаблону, який називається «схема», у якому автор контракту лише коригує параметри та права власності, як це робиться з традиційними юридичними контрактами. Наразі в RGB існує два типи схем: одна для випуску взаємозамінних токенів (RGB20) і другий для видачі предметів колекціонування (RGB21), але в майбутньому будь-хто зможе розробити більше схем без дозволу, не вимагаючи змін на рівні протоколу.

Щоб використати більш практичний приклад, емітент взаємозамінних активів (наприклад, акцій компанії, стейблкойнів тощо) може використати шаблон схеми RGB20 і створити контракт із визначенням кількості токенів, які він випустить, назвою активу та деякими додатковими пов’язаними метаданими. з цим. Потім він може визначити, який біткойн UTXO має право передавати право власності на створені токени та призначати інші права іншим UTXO, наприклад право здійснювати вторинний випуск або переномінувати актив. Кожен клієнт, який отримує токени, створені за цим контрактом, зможе перевірити зміст контракту Genesis і підтвердити, що будь-яка передача права власності в історії отриманого токена відповідає правилам, викладеним у ньому.

Отже, що ми можемо зробити з RGB на практиці сьогодні? Перш за все, це дозволяє випускати та передавати токенізовані активи з кращою масштабованістю та конфіденційністю порівняно з будь-якою існуючою альтернативою. З точки зору конфіденційності, переваги RGB полягає в тому, що всі пов’язані з передачею дані зберігаються на стороні клієнта, тому спостерігач за блокчейном не може отримати будь-яку інформацію про фінансову діяльність користувача (навіть неможливо відрізнити транзакцію біткойна, яка містить зобов’язання RGB). від звичайного), крім того, одержувач ділиться з відправником лише засліпленим UTXO (тобто хеш конкатенації між UTXO, у якому вона хоче отримати активи, і випадковим числом) замість самого UTXO, тому це не можливість платника контролювати подальшу діяльність одержувача. Щоб ще більше підвищити конфіденційність користувачів, RGB також застосовує куленепробивний криптографічний механізм, щоб приховати суми в історії передачі активів, щоб навіть майбутні власники активів мали неясне уявлення про фінансову поведінку попередніх власників.

З точки зору масштабованості, RGB також пропонує деякі переваги. По-перше, більшість даних зберігається поза ланцюгом, оскільки блокчейн використовується лише як рівень зобов’язань, що зменшує комісії, які потрібно сплачувати, і означає, що кожен клієнт підтверджує лише ті перекази, які його цікавлять, а не всі діяльність глобальної мережі. Оскільки для переказу RGB все ще потрібна транзакція Bitcoin, економія комісії може здатися мінімальною, але коли ви починаєте запроваджувати групування транзакцій, вона може швидко стати масовою. Дійсно, можна передати всі токени (або, загалом, «права»), пов’язані з UTXO, будь-якій кількості одержувачів за допомогою єдиного зобов’язання в одній транзакції біткойнів. Припустімо, ви постачальник послуг, який здійснює виплати кільком користувачам одночасно. За допомогою RGB ви можете здійснити в одній транзакції Bitcoin тисячі переказів тисячам користувачів, які запитують різні типи активів, роблячи граничну вартість кожної окремої виплати абсолютно незначною.

Ще один механізм економії комісій для емітентів невеликих активів полягає в тому, що в RGB випуск активу не вимагає сплати комісій. Це відбувається тому, що створення емісійного контракту не потрібно фіксувати в блокчейні. Контракт просто визначає, до якого вже існуючого UTXO будуть розподілені щойно випущені активи. Отже, якщо ви митець, зацікавлений у створенні колекційних жетонів, ви можете випускати скільки завгодно безкоштовно, а потім платити комісію за транзакцію біткойнів лише тоді, коли з’являється покупець і просить призначити токен до свого UTXO.

Крім того, оскільки RGB побудований на основі транзакцій біткойнів, він також сумісний із Lightning Network. Хоча це ще не реалізовано на момент написання статті, можна буде створювати канали Lightning для окремих активів і направляти платежі через них, подібно до того, як це працює зі звичайними транзакціями Lightning.

Висновок

RGB — це новаторська інновація, яка відкриває нові випадки використання з використанням абсолютно нової парадигми, але які інструменти доступні для її використання? Якщо ви хочете поекспериментувати з ядром самої технології, вам слід безпосередньо спробувати Вузол RGB. Якщо ви хочете створювати програми на основі RGB без необхідності глибоко занурюватися в складність протоколу, ви можете використовувати бібліотека rgb-lib, який забезпечує простий інтерфейс для розробників. Якщо ви просто хочете спробувати випустити та передати активи, ви можете пограти з Гаманець Iris для Android, код якого також є відкритим кодом GitHub. Якщо ви просто хочете дізнатися більше про RGB, ви можете перевірити цей список ресурсів.

Це гостьовий пост від Федеріко Тенга. Висловлені думки повністю належать їм і не обов’язково збігаються з думками BTC Inc або Bitcoin Magazine.