У цій статті зроблено спробу надати стислий опис RGB, протоколу емісії активів на біткойнах (його також можна розуміти як систему смарт-контрактів поза мережею), і вказує на те, що він дуже відрізняється від інших проектів, які щоб досягти однакових або схожих функціональних протоколів, ці відмінності роблять протокол RGB набагато більш масштабованим, ніж вони, і залишають ширший простір для програмування. Окрім представлення готових проектів RGB, ми також дослідимо ці можливості програмування.
Що таке протокол RGB?
Ідея випуску активів на біткоіни існує вже давно. Але протокол Bitcoin має свої особливості: його стан виражається лише Bitcoin UTXO («вихід невитраченої транзакції»); UTXO містить лише дві дані: власний номінал (вартість Bitcoin) і «відкритий ключ сценарію» (також відомий як «сценарій блокування»), який використовується для програмування умов витрачання цього фонду, наприклад: надання підпису певного відкритого ключа; надання коду операції, який використовується для програмування сценарію блокування, на визначення консенсусних правил біткойна за умови, що вони не можуть використовувати для реалізації довільних правил безпеки. Таким чином, неможливо створити інші активи всередині UTXO - сценарій Bitcoin не може програмувати перевірки безпеки для цих активів. Це означає, що всі ідеї щодо випуску активів на біткойнах є по суті творчим використанням блокового простору біткойнів. Це означає, що нам потрібно розробити систему смарт-контрактів поза ланцюгом і вимагати кроків для зміни стану контракту - наприклад, контракт A змінює параметри, а B передає певну кількість певного активу C —— Інформація завантажується в блокчейн, щоб отримати останній статус системи смарт-контрактів шляхом збору цієї інформації.
Приблизна ідея дизайну полягає в тому, щоб завантажити інформацію про кроки, які змінюють стан контракту, у блокчейн біткойн без змін. Це, звичайно, працює, але стикається з кількома проблемами:
(1) Оскільки завантажується повна інформація, вона може займати більше місця в блоках. Коли користувачам потрібно змінити статус контракту (наприклад, перенесення), їм також доведеться сплачувати більше комісій за обробку в мережі. Зокрема, коли ми сподіваємося, що така позаланцюгова контрактна система має кращу програмованість, ніж біткойн, підвищення програмованості може відбутися за рахунок споживання більшого простору для блоків;
(2) Майже будь-яка інформація в блоці може змінити смарт-контракт поза ланцюгом.Тому користувачі повинні отримати всі дані блоку біткойн, щоб отримати останній статус системи контрактів поза ланцюгом, тобто це дорожче перевіряти;
(3) Залежно від дизайну системи смарт-контрактів поза ланцюгом, ви можете отримати конфіденційність, порівнянну з біткойнами, або навіть гіршу; і якщо ви можете забезпечити більшу конфіденційність, вам може знадобитися споживати більше площі. блокувати простір.
У минулому широко використовуваний протокол під назвою «Omni» не завантажував повну інформацію про транзакції поза мережевими контрактами, а лише хеш-значення транзакції. Цей підхід вирішує вищезазначені проблеми та відокремлює складність контрактних транзакцій поза ланцюгом від їхніх економічних витрат; однак користувачам все одно потрібно отримати повний обсяг даних блоку біткойн, щоб отримати останній статус протоколу Omni; крім того, це робить не розроблено спеціально для підвищення конфіденційності.
RGB використовує нову парадигму під назвою «одноразові пломби». Його використання дуже просте: RGB вимагає, щоб кожен стан кожного контракту був прив’язаний до певного UTXO біткойна; і як тільки ви хочете змінити цей стан, ви повинні витратити цей UTXO і дозволити транзакції, яка його витрачає, отримати підтвердження на блокчейні; крім того, транзакція біткойн, яка його витрачає, також повинна надати хеш вмісту переходу стану, щоб вказати UTXO, приєднаний до зміненого стану.
Для розробників RGB конструкція схожа на пластикову пломбу з номером: її легко визначити, якщо її видалено, і після видалення її не можна використовувати повторно. Однак інша точка зору полягає в тому, щоб розглядати одержимий UTXO як контейнер або керамічну скарбничку в цьому стані: якщо ви хочете дістати гроші в скарбничці, ви повинні розбити скарбничку. Потім покласти гроші всередину в нову банку.
Цей дизайн різко контрастує з попередніми протоколами, які розглядали весь блок як велику дошку для запису: використання UTXO як контейнера означає, що транзакції, які не витрачають цей UTXO, не можуть мати жодного впливу на стан контракту в контейнері. Тому для перевірки певного стану певного контракту, нам не потрібно отримувати дані всіх блоків.Все, що нам потрібно, це серія транзакцій Bitcoin, докази того, що ці транзакції Bitcoin існують у певному блоці, і ці біти Перетворення стану RGB, обіцяне достатньо обміну валюти (пара один до одного з відповідною транзакцією Bitcoin). Ці дані, які можна з’єднати в ланцюжок, повинні дозволити нам відстежити початковий стан цього контракту, дозволяючи визначити суть цього стану.
Для читачів, які знайомі з мережевими системами смарт-контрактів (такими як Ethereum), одна річ, яку важко зрозуміти в цьому процесі, полягає в тому, що якщо він не покладається на консенсус блокчейну (це означає, що початковий стан контракт і кожна зміна стану перевірятиметься кожним вузлом), як гарантується безпека цієї системи розумних контрактів? Як переконатися, що активи ви отримуєте саме ті, які вам потрібні, і як переконатися, що активи не були видані незаконно?
Відповідь також дуже проста, вона називається "перевірка на стороні клієнта" - ви перевіряєте це самостійно. У контрактній системі on-chain вузли перевіряють кожну операцію переходу стану відповідно до загальнодоступних правил переходу стану, відхиляють недійсні операції, а потім обчислюють останній стан на основі початкового стану. Однак, поки відомі правила переходу стану та початковий стан, перевірка за допомогою консенсусу в ланцюжку не є єдиним способом. Користувачі можуть перевірити, чи кожен крок переходу стану відповідає початково визначеному переходу стану на основі інформації, наданої платник правило. Таким чином, перевіряюча сторона (передбачається, що вона є одержувачем активу) також може виявити незаконні зміни стану та відмовити в їх прийнятті.
Нарешті, ми використовуємо приклад, щоб продемонструвати характеристики протоколу RGB:
Тепер Аліса володіє UTXO A, який містить X одиниць активу Y, випущених згідно з протоколом RGB. Вона хоче передати Z одиниць Y Бобу. Ця партія активів пройшла через 5 попередніх власників (включаючи емітента активів), перш ніж потрапити до рук Аліси. Таким чином, Аліса повинна надати Бобу докази цих чотирьох переходів між станами (перші три з яких надав Алісі попередній власник), включаючи початковий стан контракту та правила переходу між станами, а також біти, які використовуються для кожної передачі Транзакції біткойн, транзакції RGB, здійснені кожною біржею біткойн, і докази того, що ці транзакції біткойн були підтверджені певним блоком, надсилаються Бобу. Боб перевірить, чи ці чотири перекази не порушують правила відповідно до правил переходу стану. контракту. , а потім вирішити, чи приймати його. Коли Аліса створює транзакцію RGB, оскільки Z менше за X, вона також повинна організувати для себе UTXO, щоб отримати частину, що залишилася. Нарешті, Аліса вбудовує хеш-значення цієї транзакції RGB в транзакцію Bitcoin, яка коштує UTXO A' для завершення платежу.
Нарешті, завдяки використанню контейнерів UTXO останній стан контракту RGB можна представити як точку на спрямованому ациклічному графі, який не має нащадків (кожна точка представляє стан, що зберігається в контейнері UTXO). Крім того, для власника P на малюнку нижче він знатиме лише процес із початкового стану G контракту, щоб досягти його, тобто процес, позначений червоним колом, і нічого не знатиме про сірі точки:
ПЕРЕВАГИ #RGB
Легкий стан, який можна перевірити
Як згадувалося вище, порівняно з попередніми протоколами видачі активів (контрактними системами поза ланцюгом), які з’явилися на біткойнах, RGB значно знижує вартість верифікації (певного стану контракту). Під час транзакції одержувачу більше не потрібно проходити всі блоки, щоб зібрати інформацію про зміни в статусі контракту, йому потрібно лише отримати серію транзакцій Bitcoin, а також RGB-транзакції, обіцяні цими біржами, і блоки цих Bitcoin. трансакції містять докази (на основі доказів Merkle у заголовку блоку), ви можете бути впевнені, що платник дійсно володіє певною кількістю певного активу.
Це зменшення витрат на перевірку також значно зменшує залежність (довіру) користувачів від великих постачальників інфраструктури. У попередніх протоколах, через високу вартість перевірки, користувачам було важко самостійно обчислити останній статус контракту, тому користувачі повинні були довіряти деяким постачальникам (наприклад, постачальнику статусу контракту, який використовується їхнім гаманцем); водночас часу, оскільки вони могли собі це дозволити. Менше постачальників для розрахунку витрат, що також означає централізацію постачальників. Але в RGB користувачам потрібно лише використовувати легкий клієнт Bitcoin, щоб перевірити частину транзакції з Bitcoin, і протокол RGB, щоб перевірити частину транзакції RGB, і вони можуть собі це дозволити.
У порівнянні з деякими мережевими контрактними системами, RGB також світліший. Це відображається в тому, що RGB може спеціально перевіряти певний стан контракту; у тих системах, які не базуються на UTXO, через відсутність механізму контролю доступу, як UTXO, будь-яка транзакція може змінити будь-який стан, тому ви Майже неможливо конкретно перевірити певний стан, але можна лише визначити певний стан під час обчислення всіх останніх станів - у цьому сенсі характеристики, виражені як «глобальний стан», насправді повинні бути Це називається «однорідним станом». Хоча це забезпечує функцію перехресного доступу між контрактами, це також визначає, що вартість його перевірки буде вищою, і буде важче отримати недовіру.
У цих on-chain контрактних протоколах основним заходом оптимізації є вимога до заголовка блоку фіксувати останній стан («кореневий стан»), таким чином дозволяючи легким клієнтам перевіряти певний стан контракту, отриманого від повного вузла на основі ці зобов'язання.. Це метод повторного використання обчислень, які вже відбулися (обчислень, які були запущені повним вузлом), і він також дуже ефективний, тому, якщо не враховувати надійність, його можна вважати більш ефективним, ніж RGB. Однак це означає, що легкі вузли покладаються на повні вузли для базової перевірки транзакцій і розрахунку статусу контракту. У гаманці RGB, який використовує легкий клієнт Bitcoin, припущення довіри, на яке він спирається, полягає в тому, що відповідна транзакція Bitcoin є дійсною транзакцією, а частина, пов’язана зі статусом контракту, була особисто перевірена клієнтом, тому вона є більш надійною. безкоштовно.. Недоліком є те, що затримка підтвердження є довшою, і потрібно зберігати більше даних.
Масштабованість
Масштабованість RGB відображається в двох аспектах:
У транзакцію біткойн вбудовано лише хеш-значення, що означає відсутність обмежень на обсяг транзакції RGB (за винятком спеціальних правил контракту) — навіть якщо ви розділите один актив RGB на 100 частин (транзакція RGB сам по собі буде дуже великим), і існує лише одне хеш-значення, яке потрібно вбудувати в транзакцію Bitcoin. Як згадувалося в Примітці 6, є два способи вбудувати таке хеш-значення: один полягає у використанні виводу OP_RETURN, що означає, що він споживатиме простір у ланцюжку хеш-значення; інший — приховати загальнодоступний вихід сценарію у ключі Taproot - це не займає місця в ланцюжку. Це також означає, що користувачам не потрібно жертвувати економічністю заради програмованості — лише враховуючи комісію в мережі.
Останній стан контракту RGB є незалежною точкою на орієнтованому ациклічному графі без нащадків — це означає, що ці стани можна змінювати незалежно, не впливаючи один на одного, що означає, що допускається паралелізм. Насправді це функція, успадкована від UTXO. Це також означає, що недійсні зміни (недійсні транзакції), які відбуваються в одній гілці, не вплинуть на інші гілки, не кажучи вже про те, що весь контракт застрягне, тому це також можна розглядати як перевагу безпеки.
Одним із моментів, який піддається критиці через масштабованість RGB, є те, що кожна передача вимагає від одержувача перевірки всіх залучених транзакцій від початкового стану до стану платника – у міру того, як збільшується кількість переходів активу з рук в руки, збільшується навантаження перевірки на наступних одержувачів. ставатиме все важчим і важчим. Ця критика правдива. Оптимізація означає, що нам також потрібно знайти спосіб повторного використання операцій, які вже відбулися. Технології надійних систем, такі як SNARK, обіцяють забезпечити таке рішення.
Диференціація визначення активів і механізм зберігання
Остання перевага все ще пов’язана з UTXO і залежить від того, як ми розуміємо механізм сценарію блокування UTXO.
Сценарій блокування можна використовувати для програмування умов розблокування для фонду і, отже, він може реалізувати правила зберігання. Наприклад, якщо сценарій блокування містить один і тільки один відкритий ключ, це означає, що ним може керувати лише власник відповідного закритого ключа. Однак такі правила зберігання також є основою для програмування протоколу контракту Bitcoin. Наприклад, UTXO, що використовує сценарій блокування з кількома підписами 2 з 2, може бути блискавичним каналом; під час роботи каналу дві сторони можуть платити одна одній майже незліченну кількість разів без будь-яких змін у формі онлайн-ланцюжка кошти. Іншими словами, наразі сценарій блокування з кількома підписами 2 із 2 являє собою механізм передачі вартості, який дозволяє обом сторонам передавати цінність без зміни форми коштів у ланцюжку.
Такий механізм можна використовувати для вартості біткойнів, які передає UTXO. Природно, він також може використовуватися для активів RGB, які він передає. Ми можемо випустити актив RGB і прикріпити його до UTXO з кількома підписами 2 з 2, таким чином використовуючи механізм каналу блискавки, щоб оплачувати цей актив один одному необмежену кількість разів. Таким же чином активи RGB також можна вводити в інші контракти на основі сценаріїв Bitcoin.
Тут сценарій UTXO і протокол RGB формують функціональну диференціацію: перший спрямований на реалізацію правил зберігання та передачі цінностей, тоді як другий зосереджений на визначенні активів. Таким чином, зберігання активів і визначення активів можна розділити. Це важливе покращення безпеки та те, до чого люди прагнули в деяких інших мережевих контрактних системах.
Дизайн RGB вже створений
Наведені вище характеристики фактично справедливі для всіх протоколів, заснованих на одноразовому запечатуванні UTXO та перевірці клієнта. Але на цій основі протокол RGB був розроблений далі.
У поточній розробці протоколу RGB розробники особливо стурбовані конфіденційністю протоколу, тому RGB посилює конфіденційність у двох аспектах:
Сліпий UTXO. У транзакції RGB одержувачу потрібно лише використовувати обфускований ідентифікатор UTXO, щоб отримати актив, не розкриваючи характеристики UTXO, який фактично отримав актив. Це не впливає на здатність одержувача надати докази наступному власнику, водночас дозволяючи наступним одержувачам активів захистити себе від цікавих очей попереднього власника активів.
Куленепробивний. Можна використовувати, щоб приховати конкретну суму в кожній транзакції. Однак наступні власники активів все ще можуть перевірити, що раніше не було додаткової емісії.
Простір для дослідження
У цьому розділі я обговорюватиму простір, який може продовжувати досліджувати протокол RGB, головним чином пов’язаний із програмованістю.
Наразі запропоновані шаблони (схеми) контрактів RGB зосереджені на випуску активів. Однак, оскільки RGB використовує парадигму «перевірки на стороні клієнта», ми фактично можемо додати до неї будь-які характеристики, які можуть бути забезпечені перевіркою на стороні клієнта — лише обмежені структурою UTXO.
Обмеження
На основі UTXO концепція, яка може розширити програмованість, називається "ковенанти". Початковий намір положення про обмеження полягає в тому, щоб обмежити пункт призначення, куди можна переказати суму грошей. За допомогою цієї можливості ми можемо програмувати багато цікавих програм, таких як:
Фондовий пул для неінтерактивного зняття коштів. Ми можемо об’єднати кошти багатьох людей в одному UTXO та використовувати положення про обмеження, щоб гарантувати, що будь-хто з них може виводити власні кошти без допомоги інших. Це може допомогти людям залишити місця високого ризику за низькою ціною, коли попит на блок-простір високий.
Договір про сховище. Кошти спочатку потрібно кудись витратити та пройти через часове блокування, перш ніж його можна буде витрачати вільно; протягом періоду тимчасового блокування власник сейфа може перервати цей процес екстреним ключем і негайно перевести кошти в інше місце. Цей пристрій може стати чудовою підмогою для автономної опіки.
Поточний Bitcoin Script не має такої можливості, тому для ввімкнення обмежень для Bitcoin Script потрібен soft fork.
Однак, поки ми готові пожертвувати деякими перевагами, які приносить «диференціація визначення активів і механізмів зберігання», ми можемо експериментувати з такими функціями на активах RGB. Ми можемо реалізувати такі функції на рівні контракту RGB, хоча це може Не працює лише для активів RGB, які його використовують (а не біткойнів), але точно відкриє цікавий простір.
Існуючі дослідження положень про обмеження показують, що це може розширити простір програмування транзакцій на основі UTXO та надати багато функцій. Але ці дослідження в основному базуються на біткойнах, а щодо таких протоколів, як біткойн, ми будемо більш консервативними. Що стосується RGB, ми можемо сміливо узагальнити основну можливість положень обмежень - здатність читати транзакції, які витрачаються на рівні сценарію - щоб забезпечити більш гнучку програмованість: можливість перехресного доступу до контрактів.
Перехресний доступ
Мінімально обмежувальні терміни означають, що коли UTXO витрачається, його сценарій може читати вихідні дані транзакції витрачання. Але повністю узагальнене обмеження означає, що воно може читати всі частини транзакції, яка його витратила. Це означає, що він також може читати інші вхідні дані транзакції.Якщо ми не обмежуємо інші вхідні дані з того самого контракту, це означає, що він може читати статус інших контрактів.
У RGB за замовчуванням кожен контракт є незалежним всесвітом із власним спрямованим ациклічним графом. Однак користувач все ще може мати статус двох різних контрактів одночасно. Якби транзакції RGB дозволяли одночасне витрачання активів з обох контрактів, такі можливості перехресного доступу могли б мати застосування (хоча це могло б ускладнити перевірку транзакцій).
Насправді вже існують контрактні системи в ланцюжку, засновані на подібних структурах UTXO (наприклад: мережа Nervos), які використовують це для досягнення можливостей перехресного доступу контрактів. Це дуже нове поле, яке відкривається в областях, які рідко торкалися попередні дослідження біткойнів, і тут можуть бути приховані деякі сюрпризи.
на закінчення
У цій статті читачі побачать, що існує поняття, яке часто згадується і проходить через усі процеси міркування та фантазії: «UTXO». Це саме мій намір. Якщо ви не розумієте UTXO, ви не зможете зрозуміти початкову точку дизайну протоколу, такого як RGB, а також не зможете зрозуміти переваги дизайну протоколу RGB, а також не зможете уявити, як люди його використовують. Характеристики протоколу RGB значною мірою визначаються його одноразовою запечатаною формою UTXO. Відповідно, дослідження UTXO, накопичені в дослідницькій галузі Bitcoin, також можуть бути застосовані до досліджень RGB.
Це також пояснює, чому людям, які не розуміють біткойн, буде важко зрозуміти RGB. Люди, які люблять біткойни, впізнають дизайн, створений RGB.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
Зрозумійте справжній потенціал протоколу випуску активів RGB в одній статті
Автор: А Цзянь
У цій статті зроблено спробу надати стислий опис RGB, протоколу емісії активів на біткойнах (його також можна розуміти як систему смарт-контрактів поза мережею), і вказує на те, що він дуже відрізняється від інших проектів, які щоб досягти однакових або схожих функціональних протоколів, ці відмінності роблять протокол RGB набагато більш масштабованим, ніж вони, і залишають ширший простір для програмування. Окрім представлення готових проектів RGB, ми також дослідимо ці можливості програмування.
Що таке протокол RGB?
Ідея випуску активів на біткоіни існує вже давно. Але протокол Bitcoin має свої особливості: його стан виражається лише Bitcoin UTXO («вихід невитраченої транзакції»); UTXO містить лише дві дані: власний номінал (вартість Bitcoin) і «відкритий ключ сценарію» (також відомий як «сценарій блокування»), який використовується для програмування умов витрачання цього фонду, наприклад: надання підпису певного відкритого ключа; надання коду операції, який використовується для програмування сценарію блокування, на визначення консенсусних правил біткойна за умови, що вони не можуть використовувати для реалізації довільних правил безпеки. Таким чином, неможливо створити інші активи всередині UTXO - сценарій Bitcoin не може програмувати перевірки безпеки для цих активів. Це означає, що всі ідеї щодо випуску активів на біткойнах є по суті творчим використанням блокового простору біткойнів. Це означає, що нам потрібно розробити систему смарт-контрактів поза ланцюгом і вимагати кроків для зміни стану контракту - наприклад, контракт A змінює параметри, а B передає певну кількість певного активу C —— Інформація завантажується в блокчейн, щоб отримати останній статус системи смарт-контрактів шляхом збору цієї інформації.
Приблизна ідея дизайну полягає в тому, щоб завантажити інформацію про кроки, які змінюють стан контракту, у блокчейн біткойн без змін. Це, звичайно, працює, але стикається з кількома проблемами:
(1) Оскільки завантажується повна інформація, вона може займати більше місця в блоках. Коли користувачам потрібно змінити статус контракту (наприклад, перенесення), їм також доведеться сплачувати більше комісій за обробку в мережі. Зокрема, коли ми сподіваємося, що така позаланцюгова контрактна система має кращу програмованість, ніж біткойн, підвищення програмованості може відбутися за рахунок споживання більшого простору для блоків;
(2) Майже будь-яка інформація в блоці може змінити смарт-контракт поза ланцюгом.Тому користувачі повинні отримати всі дані блоку біткойн, щоб отримати останній статус системи контрактів поза ланцюгом, тобто це дорожче перевіряти;
(3) Залежно від дизайну системи смарт-контрактів поза ланцюгом, ви можете отримати конфіденційність, порівнянну з біткойнами, або навіть гіршу; і якщо ви можете забезпечити більшу конфіденційність, вам може знадобитися споживати більше площі. блокувати простір.
У минулому широко використовуваний протокол під назвою «Omni» не завантажував повну інформацію про транзакції поза мережевими контрактами, а лише хеш-значення транзакції. Цей підхід вирішує вищезазначені проблеми та відокремлює складність контрактних транзакцій поза ланцюгом від їхніх економічних витрат; однак користувачам все одно потрібно отримати повний обсяг даних блоку біткойн, щоб отримати останній статус протоколу Omni; крім того, це робить не розроблено спеціально для підвищення конфіденційності.
RGB використовує нову парадигму під назвою «одноразові пломби». Його використання дуже просте: RGB вимагає, щоб кожен стан кожного контракту був прив’язаний до певного UTXO біткойна; і як тільки ви хочете змінити цей стан, ви повинні витратити цей UTXO і дозволити транзакції, яка його витрачає, отримати підтвердження на блокчейні; крім того, транзакція біткойн, яка його витрачає, також повинна надати хеш вмісту переходу стану, щоб вказати UTXO, приєднаний до зміненого стану.
Для розробників RGB конструкція схожа на пластикову пломбу з номером: її легко визначити, якщо її видалено, і після видалення її не можна використовувати повторно. Однак інша точка зору полягає в тому, щоб розглядати одержимий UTXO як контейнер або керамічну скарбничку в цьому стані: якщо ви хочете дістати гроші в скарбничці, ви повинні розбити скарбничку. Потім покласти гроші всередину в нову банку.
Цей дизайн різко контрастує з попередніми протоколами, які розглядали весь блок як велику дошку для запису: використання UTXO як контейнера означає, що транзакції, які не витрачають цей UTXO, не можуть мати жодного впливу на стан контракту в контейнері. Тому для перевірки певного стану певного контракту, нам не потрібно отримувати дані всіх блоків.Все, що нам потрібно, це серія транзакцій Bitcoin, докази того, що ці транзакції Bitcoin існують у певному блоці, і ці біти Перетворення стану RGB, обіцяне достатньо обміну валюти (пара один до одного з відповідною транзакцією Bitcoin). Ці дані, які можна з’єднати в ланцюжок, повинні дозволити нам відстежити початковий стан цього контракту, дозволяючи визначити суть цього стану.
Для читачів, які знайомі з мережевими системами смарт-контрактів (такими як Ethereum), одна річ, яку важко зрозуміти в цьому процесі, полягає в тому, що якщо він не покладається на консенсус блокчейну (це означає, що початковий стан контракт і кожна зміна стану перевірятиметься кожним вузлом), як гарантується безпека цієї системи розумних контрактів? Як переконатися, що активи ви отримуєте саме ті, які вам потрібні, і як переконатися, що активи не були видані незаконно?
Відповідь також дуже проста, вона називається "перевірка на стороні клієнта" - ви перевіряєте це самостійно. У контрактній системі on-chain вузли перевіряють кожну операцію переходу стану відповідно до загальнодоступних правил переходу стану, відхиляють недійсні операції, а потім обчислюють останній стан на основі початкового стану. Однак, поки відомі правила переходу стану та початковий стан, перевірка за допомогою консенсусу в ланцюжку не є єдиним способом. Користувачі можуть перевірити, чи кожен крок переходу стану відповідає початково визначеному переходу стану на основі інформації, наданої платник правило. Таким чином, перевіряюча сторона (передбачається, що вона є одержувачем активу) також може виявити незаконні зміни стану та відмовити в їх прийнятті.
Нарешті, ми використовуємо приклад, щоб продемонструвати характеристики протоколу RGB:
Тепер Аліса володіє UTXO A, який містить X одиниць активу Y, випущених згідно з протоколом RGB. Вона хоче передати Z одиниць Y Бобу. Ця партія активів пройшла через 5 попередніх власників (включаючи емітента активів), перш ніж потрапити до рук Аліси. Таким чином, Аліса повинна надати Бобу докази цих чотирьох переходів між станами (перші три з яких надав Алісі попередній власник), включаючи початковий стан контракту та правила переходу між станами, а також біти, які використовуються для кожної передачі Транзакції біткойн, транзакції RGB, здійснені кожною біржею біткойн, і докази того, що ці транзакції біткойн були підтверджені певним блоком, надсилаються Бобу. Боб перевірить, чи ці чотири перекази не порушують правила відповідно до правил переходу стану. контракту. , а потім вирішити, чи приймати його. Коли Аліса створює транзакцію RGB, оскільки Z менше за X, вона також повинна організувати для себе UTXO, щоб отримати частину, що залишилася. Нарешті, Аліса вбудовує хеш-значення цієї транзакції RGB в транзакцію Bitcoin, яка коштує UTXO A' для завершення платежу.
Нарешті, завдяки використанню контейнерів UTXO останній стан контракту RGB можна представити як точку на спрямованому ациклічному графі, який не має нащадків (кожна точка представляє стан, що зберігається в контейнері UTXO). Крім того, для власника P на малюнку нижче він знатиме лише процес із початкового стану G контракту, щоб досягти його, тобто процес, позначений червоним колом, і нічого не знатиме про сірі точки:
ПЕРЕВАГИ #RGB
Легкий стан, який можна перевірити
Як згадувалося вище, порівняно з попередніми протоколами видачі активів (контрактними системами поза ланцюгом), які з’явилися на біткойнах, RGB значно знижує вартість верифікації (певного стану контракту). Під час транзакції одержувачу більше не потрібно проходити всі блоки, щоб зібрати інформацію про зміни в статусі контракту, йому потрібно лише отримати серію транзакцій Bitcoin, а також RGB-транзакції, обіцяні цими біржами, і блоки цих Bitcoin. трансакції містять докази (на основі доказів Merkle у заголовку блоку), ви можете бути впевнені, що платник дійсно володіє певною кількістю певного активу.
Це зменшення витрат на перевірку також значно зменшує залежність (довіру) користувачів від великих постачальників інфраструктури. У попередніх протоколах, через високу вартість перевірки, користувачам було важко самостійно обчислити останній статус контракту, тому користувачі повинні були довіряти деяким постачальникам (наприклад, постачальнику статусу контракту, який використовується їхнім гаманцем); водночас часу, оскільки вони могли собі це дозволити. Менше постачальників для розрахунку витрат, що також означає централізацію постачальників. Але в RGB користувачам потрібно лише використовувати легкий клієнт Bitcoin, щоб перевірити частину транзакції з Bitcoin, і протокол RGB, щоб перевірити частину транзакції RGB, і вони можуть собі це дозволити.
У порівнянні з деякими мережевими контрактними системами, RGB також світліший. Це відображається в тому, що RGB може спеціально перевіряти певний стан контракту; у тих системах, які не базуються на UTXO, через відсутність механізму контролю доступу, як UTXO, будь-яка транзакція може змінити будь-який стан, тому ви Майже неможливо конкретно перевірити певний стан, але можна лише визначити певний стан під час обчислення всіх останніх станів - у цьому сенсі характеристики, виражені як «глобальний стан», насправді повинні бути Це називається «однорідним станом». Хоча це забезпечує функцію перехресного доступу між контрактами, це також визначає, що вартість його перевірки буде вищою, і буде важче отримати недовіру.
У цих on-chain контрактних протоколах основним заходом оптимізації є вимога до заголовка блоку фіксувати останній стан («кореневий стан»), таким чином дозволяючи легким клієнтам перевіряти певний стан контракту, отриманого від повного вузла на основі ці зобов'язання.. Це метод повторного використання обчислень, які вже відбулися (обчислень, які були запущені повним вузлом), і він також дуже ефективний, тому, якщо не враховувати надійність, його можна вважати більш ефективним, ніж RGB. Однак це означає, що легкі вузли покладаються на повні вузли для базової перевірки транзакцій і розрахунку статусу контракту. У гаманці RGB, який використовує легкий клієнт Bitcoin, припущення довіри, на яке він спирається, полягає в тому, що відповідна транзакція Bitcoin є дійсною транзакцією, а частина, пов’язана зі статусом контракту, була особисто перевірена клієнтом, тому вона є більш надійною. безкоштовно.. Недоліком є те, що затримка підтвердження є довшою, і потрібно зберігати більше даних.
Масштабованість
Масштабованість RGB відображається в двох аспектах:
У транзакцію біткойн вбудовано лише хеш-значення, що означає відсутність обмежень на обсяг транзакції RGB (за винятком спеціальних правил контракту) — навіть якщо ви розділите один актив RGB на 100 частин (транзакція RGB сам по собі буде дуже великим), і існує лише одне хеш-значення, яке потрібно вбудувати в транзакцію Bitcoin. Як згадувалося в Примітці 6, є два способи вбудувати таке хеш-значення: один полягає у використанні виводу OP_RETURN, що означає, що він споживатиме простір у ланцюжку хеш-значення; інший — приховати загальнодоступний вихід сценарію у ключі Taproot - це не займає місця в ланцюжку. Це також означає, що користувачам не потрібно жертвувати економічністю заради програмованості — лише враховуючи комісію в мережі.
Останній стан контракту RGB є незалежною точкою на орієнтованому ациклічному графі без нащадків — це означає, що ці стани можна змінювати незалежно, не впливаючи один на одного, що означає, що допускається паралелізм. Насправді це функція, успадкована від UTXO. Це також означає, що недійсні зміни (недійсні транзакції), які відбуваються в одній гілці, не вплинуть на інші гілки, не кажучи вже про те, що весь контракт застрягне, тому це також можна розглядати як перевагу безпеки.
Одним із моментів, який піддається критиці через масштабованість RGB, є те, що кожна передача вимагає від одержувача перевірки всіх залучених транзакцій від початкового стану до стану платника – у міру того, як збільшується кількість переходів активу з рук в руки, збільшується навантаження перевірки на наступних одержувачів. ставатиме все важчим і важчим. Ця критика правдива. Оптимізація означає, що нам також потрібно знайти спосіб повторного використання операцій, які вже відбулися. Технології надійних систем, такі як SNARK, обіцяють забезпечити таке рішення.
Диференціація визначення активів і механізм зберігання
Остання перевага все ще пов’язана з UTXO і залежить від того, як ми розуміємо механізм сценарію блокування UTXO.
Сценарій блокування можна використовувати для програмування умов розблокування для фонду і, отже, він може реалізувати правила зберігання. Наприклад, якщо сценарій блокування містить один і тільки один відкритий ключ, це означає, що ним може керувати лише власник відповідного закритого ключа. Однак такі правила зберігання також є основою для програмування протоколу контракту Bitcoin. Наприклад, UTXO, що використовує сценарій блокування з кількома підписами 2 з 2, може бути блискавичним каналом; під час роботи каналу дві сторони можуть платити одна одній майже незліченну кількість разів без будь-яких змін у формі онлайн-ланцюжка кошти. Іншими словами, наразі сценарій блокування з кількома підписами 2 із 2 являє собою механізм передачі вартості, який дозволяє обом сторонам передавати цінність без зміни форми коштів у ланцюжку.
Такий механізм можна використовувати для вартості біткойнів, які передає UTXO. Природно, він також може використовуватися для активів RGB, які він передає. Ми можемо випустити актив RGB і прикріпити його до UTXO з кількома підписами 2 з 2, таким чином використовуючи механізм каналу блискавки, щоб оплачувати цей актив один одному необмежену кількість разів. Таким же чином активи RGB також можна вводити в інші контракти на основі сценаріїв Bitcoin.
Тут сценарій UTXO і протокол RGB формують функціональну диференціацію: перший спрямований на реалізацію правил зберігання та передачі цінностей, тоді як другий зосереджений на визначенні активів. Таким чином, зберігання активів і визначення активів можна розділити. Це важливе покращення безпеки та те, до чого люди прагнули в деяких інших мережевих контрактних системах.
Дизайн RGB вже створений
Наведені вище характеристики фактично справедливі для всіх протоколів, заснованих на одноразовому запечатуванні UTXO та перевірці клієнта. Але на цій основі протокол RGB був розроблений далі.
У поточній розробці протоколу RGB розробники особливо стурбовані конфіденційністю протоколу, тому RGB посилює конфіденційність у двох аспектах:
Сліпий UTXO. У транзакції RGB одержувачу потрібно лише використовувати обфускований ідентифікатор UTXO, щоб отримати актив, не розкриваючи характеристики UTXO, який фактично отримав актив. Це не впливає на здатність одержувача надати докази наступному власнику, водночас дозволяючи наступним одержувачам активів захистити себе від цікавих очей попереднього власника активів.
Куленепробивний. Можна використовувати, щоб приховати конкретну суму в кожній транзакції. Однак наступні власники активів все ще можуть перевірити, що раніше не було додаткової емісії.
Простір для дослідження
У цьому розділі я обговорюватиму простір, який може продовжувати досліджувати протокол RGB, головним чином пов’язаний із програмованістю.
Наразі запропоновані шаблони (схеми) контрактів RGB зосереджені на випуску активів. Однак, оскільки RGB використовує парадигму «перевірки на стороні клієнта», ми фактично можемо додати до неї будь-які характеристики, які можуть бути забезпечені перевіркою на стороні клієнта — лише обмежені структурою UTXO.
Обмеження
На основі UTXO концепція, яка може розширити програмованість, називається "ковенанти". Початковий намір положення про обмеження полягає в тому, щоб обмежити пункт призначення, куди можна переказати суму грошей. За допомогою цієї можливості ми можемо програмувати багато цікавих програм, таких як:
Фондовий пул для неінтерактивного зняття коштів. Ми можемо об’єднати кошти багатьох людей в одному UTXO та використовувати положення про обмеження, щоб гарантувати, що будь-хто з них може виводити власні кошти без допомоги інших. Це може допомогти людям залишити місця високого ризику за низькою ціною, коли попит на блок-простір високий.
Договір про сховище. Кошти спочатку потрібно кудись витратити та пройти через часове блокування, перш ніж його можна буде витрачати вільно; протягом періоду тимчасового блокування власник сейфа може перервати цей процес екстреним ключем і негайно перевести кошти в інше місце. Цей пристрій може стати чудовою підмогою для автономної опіки.
Поточний Bitcoin Script не має такої можливості, тому для ввімкнення обмежень для Bitcoin Script потрібен soft fork.
Однак, поки ми готові пожертвувати деякими перевагами, які приносить «диференціація визначення активів і механізмів зберігання», ми можемо експериментувати з такими функціями на активах RGB. Ми можемо реалізувати такі функції на рівні контракту RGB, хоча це може Не працює лише для активів RGB, які його використовують (а не біткойнів), але точно відкриє цікавий простір.
Існуючі дослідження положень про обмеження показують, що це може розширити простір програмування транзакцій на основі UTXO та надати багато функцій. Але ці дослідження в основному базуються на біткойнах, а щодо таких протоколів, як біткойн, ми будемо більш консервативними. Що стосується RGB, ми можемо сміливо узагальнити основну можливість положень обмежень - здатність читати транзакції, які витрачаються на рівні сценарію - щоб забезпечити більш гнучку програмованість: можливість перехресного доступу до контрактів.
Перехресний доступ
Мінімально обмежувальні терміни означають, що коли UTXO витрачається, його сценарій може читати вихідні дані транзакції витрачання. Але повністю узагальнене обмеження означає, що воно може читати всі частини транзакції, яка його витратила. Це означає, що він також може читати інші вхідні дані транзакції.Якщо ми не обмежуємо інші вхідні дані з того самого контракту, це означає, що він може читати статус інших контрактів.
У RGB за замовчуванням кожен контракт є незалежним всесвітом із власним спрямованим ациклічним графом. Однак користувач все ще може мати статус двох різних контрактів одночасно. Якби транзакції RGB дозволяли одночасне витрачання активів з обох контрактів, такі можливості перехресного доступу могли б мати застосування (хоча це могло б ускладнити перевірку транзакцій).
Насправді вже існують контрактні системи в ланцюжку, засновані на подібних структурах UTXO (наприклад: мережа Nervos), які використовують це для досягнення можливостей перехресного доступу контрактів. Це дуже нове поле, яке відкривається в областях, які рідко торкалися попередні дослідження біткойнів, і тут можуть бути приховані деякі сюрпризи.
на закінчення
У цій статті читачі побачать, що існує поняття, яке часто згадується і проходить через усі процеси міркування та фантазії: «UTXO». Це саме мій намір. Якщо ви не розумієте UTXO, ви не зможете зрозуміти початкову точку дизайну протоколу, такого як RGB, а також не зможете зрозуміти переваги дизайну протоколу RGB, а також не зможете уявити, як люди його використовують. Характеристики протоколу RGB значною мірою визначаються його одноразовою запечатаною формою UTXO. Відповідно, дослідження UTXO, накопичені в дослідницькій галузі Bitcoin, також можуть бути застосовані до досліджень RGB.
Це також пояснює, чому людям, які не розуміють біткойн, буде важко зрозуміти RGB. Люди, які люблять біткойни, впізнають дизайн, створений RGB.