Будучи одним з основних принципів проектування біткоїна, модель UTXO є важливою технічною парадигмою в блокчейні з моменту його створення. Вона відіграє вирішальну роль у забезпеченні безпеки та відстежуваності транзакцій, забезпечуючи альтернативний шлях за межами традиційної моделі балансу рахунків. З постійним розвитком і розширенням технології блокчейн в останні роки, сама модель UTXO зазнає постійної еволюції і розширення, наприклад, eUTXO, комірка, список суворого доступу та інші.

У цій статті простою мовою представлено модель UTXO, надано короткий огляд моделі UTXO та методів реалізації BTC, Sui, Cardano, Nervos і Fuel.

Що таке UTXO?

Щоб проілюструвати модель UTXO, ми використаємо приклад:

Уявіть собі двох людей, Алісу і Боба, у кожного з яких спочатку було по $5. Згодом виникає конфлікт, і Аліса була пограбована Бобом на $2. Остаточні обсяги для кожного з них виглядають наступним чином:

Очевидно, що у Аліси залишається $3, а у Боба - $7. Цей елементарний арифметичний метод бухгалтерського обліку часто зустрічається в банківських системах і називається "модель рахунку/балансу". У цій моделі залишок на рахунку існує як єдине числове значення.

Якби ми застосували інший підхід, ніж модель рахунків, наприклад, використовуючи UTXO для представлення передачі багатства між Алісою та Бобом, ілюстративна діаграма набула б іншого вигляду:

На даний момент у Аліси все ще є $3, а у Боба - $7, але ці $7 не представлені єдиним числовим значенням. Натомість вони розбиті на "5 доларів" і "2 долари". Чи не здається вам, що такий нестандартний підхід дещо незвичний? Це унікальний метод обліку, відомий як UTXO.

Англійська абревіатура UTXO розшифровується як Unspent Transaction Output (невитрачений вихід транзакції). За такого підходу до обліку кожна транзакція в ланцюжку відображається як зміни та перекази в UTXO. Наприклад, у згаданій події транзакції вхідними параметрами слугують "$5", які спочатку належали Алісі, позначені як UTXO_0 і будуть позначені як витрачені; одночасно система генерує "$2" (UTXO_1) і "$3" (UTXO_2) як вихідні параметри. UTXO_1 буде передано Бобу, а UTXO_2 буде повернуто Алісі, таким чином завершивши передачу багатства між Алісою та Бобом.

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

Саме так Біткоїн веде облік: з кожною транзакцією старі UTXO знищуються, а нові створюються. Загальна кількість знищених UTXO дорівнює кількості новостворених UTXO (з частиною, що розподіляється як комісія за транзакції для майнерів). Це гарантує, що кошти не можуть бути довільно збільшені.

Порівняння між моделлю UTXO та моделлю рахунку/балансу

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

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

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

На відміну від моделі балансу рахунку, модель UTXO біткоїна краще пристосована для вирішення проблем, пов'язаних з суперечками щодо даних. За такого підходу суб'єкт безпосередньої обробки кожної транзакції - це вже не конкретний "рахунок", а окремі, незалежні UTXO. Оскільки різні UTXO не заважають один одному, кожна транзакція в мережі Біткоїн працює незалежно. В результаті, вузли мережі Біткоїн можуть обробляти декілька транзакцій одночасно без необхідності "блокування", що значно підвищує пропускну здатність системи і продуктивність паралелізму.

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

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

Обмеження UTXO біткоїна опосередковано сприяли появі "Ефіріуму". Віталік, один з перших авторів Bitcoin Magazine, добре знав про недоліки біткоїна. Модель "рахунок/баланс", яка є більш зрозумілою для більшості людей, вирішує проблеми, з якими стикається UTXO при обробці заявок з багатими державами. Як зазначив Віталік у своїй статті про Ethereum:

UTXO може бути або витраченим, або невитраченим; немає можливості для багатоступеневих контрактів або сценаріїв, які утримують будь-який інший внутрішній стан за межами цього. Це ускладнює укладання багатоетапних опціонних контрактів, децентралізованих біржових пропозицій або двоетапних протоколів криптографічних зобов'язань (необхідних для безпечних обчислювальних винагород). Це також означає, що UTXO можна використовувати лише для створення простих, одноразових контрактів, а не більш складних "державних" контрактів, таких як децентралізовані організації, і ускладнює реалізацію мета-протоколів. Двійковий стан у поєднанні з ціннісною сліпотою також означає, що інше важливе застосування - ліміти на зняття коштів - є неможливим.

Застосування, оптимізація та розширення моделі UXTO

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

1. Абстрагування значення стану, що зберігається в UTXO.

2. Абстрагуючись від власності держави.

3. Вирішення державних суперечок при розподілі UTXO.

У BTC єдиним значенням стану є кількість токенів, власність зазвичай визначається за допомогою публічних ключів, а суперечки щодо стану не розглядаються широко, оскільки BTC не був розроблений для dApps.

Sui.

Sui надає розробникам два типи об'єктів: OwnedObject та SharedObject. Перша схожа на UTXO (зокрема, її вдосконалену версію), тоді як другу можна порівняти з моделлю "рахунок/баланс". Обидва можна використовувати одночасно.

Об'єкт може бути спільним, тобто будь-хто може читати або записувати до нього. На відміну від мінливого OwnedObject (з одним автором), SharedObject вимагає консенсусу для впорядкування читання і запису.

В інших блокчейнах кожен об'єкт є спільним. Однак розробники Sui зазвичай можуть використовувати OwnedObject, SharedObject або їх комбінацію для реалізації конкретних сценаріїв використання. Цей вибір може вплинути на продуктивність, безпеку та складність впровадження.

У Sui Owned Objects схожі на UTXO, і лише їхній власник може оперувати ними. Об'єкти також мають номери версій, і версія об'єкта може бути витрачена його власником лише один раз. Таким чином, версія об'єкта по суті відповідає UTXO.

Що стосується питань, пов'язаних з державними суперечками, Sui вирішує їх за допомогою спеціальної обробки (локальне замовлення, подібне до палива) в SharedObjects.

Кардано.

Cardano використовує розширену модель UTXO, відому як eUTXO. eUTXO підтримує підвищену програмованість, зберігаючи при цьому переваги моделі Bitcoin UTXO.

У Кардано значення держави ще більше розширюється за допомогою сценаріїв, а власність на державу визначається більш узагальнено. Набори UTXO використовуються для мінімізації проблем, пов'язаних з розбіжностями між державами. Зокрема, eUTXO вдосконалено у двох аспектах:

1. Модель eUTXO включає більш узагальнені адреси. Ці адреси не базуються виключно на хеші публічних ключів, але можуть бути визначені на основі будь-якої логіки, що визначає умови, за яких eUTXO можуть бути витрачені, що дозволяє програмувати державну власність.

2. Окрім адрес та значень, виходи можуть передавати (майже) будь-які дані, що дозволяє програмувати значення стану за допомогою скриптів.

Зокрема, eUTXO дозволяє користувачам додавати до UTXO довільні дані у форматі JSON, які називаються Datum. Datum дозволяє розробникам надавати функціональність, подібну до стану, для скриптів, пов'язаних з конкретними UTXO.

Більше того, транзакції на Cardano можуть містити параметри, пов'язані з конкретними користувачами, відомими як редемпери. Redeemer дозволяє ініціатору транзакції визначати, як використовувати UTXO, і може бути використаний розробниками dApp для різних цілей.

Коли транзакція валідується, скрипт валідації працює, використовуючи Datum, Redeemer і контекст, що містить дані транзакції. Цей скрипт містить логіку використання UTXO при виконанні певних умов.

Варто зазначити, що eUTXO все ще виконує завдання розширення за допомогою скриптів і суттєво відрізняється від традиційного поняття "смарт-контрактів" (Чарльз Хоскінсон, засновник, пропонує називати його "програмованим валідатором", але термін "смарт-контракти" є більш поширеним на ринку).

Нерви.

У Nervos (CKB) значення стану абстрагується за допомогою TypeScript, а право власності на стан абстрагується за допомогою lockscript. Проста модель оптимізації UTXO у вигляді клітинного коду виглядає наступним чином:

pub struct CellOutput {

    місткість пабів: Місткість,

 дані пабу: Vec<u8>,

 pub lock: Script,

 pub type_: Option<Script>,

}

Що стосується питання конфлікту станів, CKB наразі просуває дослідження відкритих транзакцій, де користувачі можуть пропонувати часткові UTXO із зазначенням мети транзакції, а потім свахи об'єднують їх у повну транзакцію.

Клітинна модель Nervos є "узагальненою" версією UTXO, і Ян надав детальне пояснення на форумі Nervos:

У центрі уваги Layer1 - стан, і, оскільки Layer1 є метою проектування, CKB, природно, зосереджується на стані.

Ethereum розділяє історію транзакцій та історію станів на два виміри, де блоки і транзакції представляють події, що викликають перехід стану, а не сам стан. На відміну від цього, протокол Bitcoin об'єднує транзакції і стани в єдиний вимір - транзакції є станом, а стан є транзакцією. Це архітектура, зосереджена навколо держави.

У той же час, CKB прагне перевіряти і зберігати не тільки nValue як стан, але й будь-які дані, які вважаються цінними і схвалені консенсусом для довгострокового збереження. Структура виводу транзакцій біткоїна неадекватна для цієї мети, але вона дала нам достатньо натхнення. Узагальнюючи nValue і перетворюючи його з простору, що зберігає цілі числа, на простір, здатний вмістити будь-які дані, ми отримуємо більш узагальнений "CTxOut" або Комірку.

У комірці nValue стає двома полями: ємність і дані. Ці поля разом представляють простір для зберігання, де ємність - це ціле число, що вказує на розмір простору в байтах, а дані - це місце, де зберігається стан і може містити будь-яку послідовність байтів. СкриптPubKey стає lock, просто змінюючи назву, яка виражає, хто є власником цього простору консенсусу - лише особа, яка може надати параметри (наприклад, підпис) для успішного виконання скрипту блокування, може "оновити" стан у цій комірці. Загальна кількість байт, яку займає весь CellOutput, має бути меншою або дорівнювати ємності. CKB має численні осередки, і їхня сукупність формує повний поточний стан CKB, зберігаючи спільні знання, а не лише конкретну цифрову валюту.

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

Характеристики цієї моделі такі:

1. Держава має першочергове значення.

2. Власність є атрибутом держави, а кожна держава має єдиного власника.

3. Держави постійно руйнуються і створюються.

Таким чином, комірка є узагальненою версією UTXO.

Паливо

Fuel використовує модель Strict Access List, яка є оптимізацією UTXO, що базується на концепції Contract UTXO.

Як було зазначено раніше, традиційні UTXO в BTC мають лише два атрибути: кількість монет і власник. На відміну від нього, контракт UTXO надає додаткові фундаментальні властивості, включаючи кількість монет, ідентифікатор контракту, хеш коду контракту і корінь сховища.

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

У цій моделі контракт UTXO, подібно до смарт-контрактів, може бути викликаний будь-ким.

Важливо відзначити, що Fuel надає функціональність, близьку до смарт-контрактів, а не до скриптів. Обмеження самої моделі UTXO роблять розробку додатків у віртуальній машині складним завданням, особливо при вирішенні проблем конфліктів UTXO. Загалом є три рішення: по-перше, обробка поза ланцюжком, наприклад, в роллапі; по-друге, попереднє секвенування додаткової роботи, яке використовує Fuel; по-третє, вищезгадана Open Transaction в CKB, де кожен користувач може пропонувати часткові транзакції, а матчмейкер (схожий на секвенсор) об'єднує їх в повні транзакції. Відповідним рішенням в BTC є PBST.

Висновок

З цієї статті ми отримали розуміння фундаментальних принципів UTXO, визнали сильні і слабкі сторони її моделі в порівнянні з моделлю рахунку/балансу Ethereum, а також отримали більш чітке уявлення про концепцію UTXO і пов'язаних з нею розширень.

Як один з основних принципів дизайну біткоїна, модель UTXO відіграє вирішальну роль у забезпеченні безпеки та відстежуваності транзакцій. З постійним розвитком і розширенням технології блокчейн розвивається модель UTXO (наприклад, EUTXO, комірка, список суворого доступу), що надає більше можливостей для транзакцій і управління цифровими активами. Завдяки глибокому дослідженню і розумінню концепції UTXO і пов'язаних з нею розширень, ми можемо краще зрозуміти суть технології блокчейн, заклавши більш міцний фундамент для майбутніх інновацій і додатків.

Відмова від відповідальності:.

1. Ця стаття передрукована з[极客 Web3], всі авторські права належать оригінальному автору[0xAyA]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.