Будучи одним из основных принципов дизайна Биткойна, модель UTXO стала важной технической парадигмой в области блокчейна с момента его создания. Она играет важнейшую роль в обеспечении безопасности и отслеживании транзакций, предоставляя альтернативный путь за пределы традиционной модели баланса счета. С непрерывным развитием и расширением технологии блокчейн в последние годы, сама модель UTXO постоянно эволюционирует и расширяется, например, eUTXO, cell, Strict access list и другие.
Эта статья знакомит с моделью UTXO на простом языке, давая краткий обзор модели UTXO и методов ее реализации в BTC, Sui, Cardano, Nervos и Fuel.
Чтобы проиллюстрировать модель 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 косвенно способствовали появлению "Ethereum". Виталик, один из самых первых авторов журнала Bitcoin Magazine, хорошо знал о недостатках Биткойна. Модель "счет/баланс", которая проще для понимания большинства людей, решает проблемы, с которыми сталкивается UTXO при работе с приложениями с богатым состоянием. Как заявил Виталик в техническом описании Ethereum:
UTXO может быть либо потрачен, либо не потрачен; здесь нет возможности для многоступенчатых контрактов или скриптов, которые сохраняют любое другое внутреннее состояние, помимо этого. Это затрудняет создание многоступенчатых опционных контрактов, децентрализованных предложений обмена или двухступенчатых криптографических протоколов обязательств (необходимых для безопасных вычислительных баунти). Это также означает, что UTXO можно использовать только для создания простых, одноразовых контрактов, а не более сложных "государственных" контрактов, таких как децентрализованные организации, и затрудняет реализацию мета-протоколов. Бинарное состояние в сочетании с "слепотой значений" также означает невозможность другого важного применения - лимитов на вывод средств.
Прежде чем перейти к рассмотрению различных применений и оптимизаций модели UTXO, давайте проанализируем области, требующие улучшения при сохранении ее преимуществ. Вкратце их можно описать следующим образом:
Абстрагирование значения состояния, хранящегося в UTXOs.
Абстрагирование права собственности на государство.
Решение проблем, связанных с содержанием, при совместном использовании UTXO.
В BTC единственным значением состояния является количество токенов, право собственности обычно определяется с помощью публичных ключей, а проблема спора состояний не рассматривается в широком смысле, поскольку BTC не был разработан для dApps.
Sui предоставляет разработчикам два типа объектов: OwnedObject и SharedObject. Первая похожа на UTXO (в частности, на расширенную версию), а вторая сравнима с моделью "счет/баланс". Оба могут использоваться одновременно.
Объект может быть общим, то есть любой может читать или писать в этот объект. В отличие от мутабельного OwnedObject (с одним писателем), SharedObject требует консенсуса для упорядочивания чтения и записи.
В других блокчейнах каждый Объект является общим. Однако разработчики Sui обычно могут выбрать использование OwnedObject, SharedObject или комбинацию обоих вариантов для реализации конкретных случаев использования. Этот выбор может повлиять на производительность, безопасность и сложность реализации.
В Sui объекты, находящиеся в собственности, похожи на UTXO, и только их владелец может оперировать ими. Объекты также имеют номера версий, и одна версия объекта может быть потрачена его владельцем только один раз. Таким образом, версия объекта по сути соответствует UTXO.
Что касается проблем, связанных с контролем состояния, Sui решает их с помощью специальной обработки (локальное упорядочивание, аналогичное Fuel) в SharedObjects.
В Cardano используется расширенная модель UTXO, известная как eUTXO. eUTXO поддерживает повышенную программируемость, сохраняя при этом преимущества модели Bitcoin UTXO.
В Cardano значение государства еще больше расширяется с помощью скриптов, а право собственности на государство определяется более обобщенно. Наборы UTXO используются, чтобы минимизировать проблемы, связанные с контролем состояния. В частности, eUTXO усовершенствован в двух аспектах:
Модель eUTXO включает в себя более обобщенные адреса. Эти адреса основаны не только на хэше открытых ключей, но могут быть определены на основе любой логики, определяющей условия, при которых eUTXO могут быть потрачены, что позволяет программировать государственную собственность.
Помимо адресов и значений, выходы могут нести (почти) любые данные, что позволяет программировать значение состояния с помощью скриптов.
Более конкретно, eUTXO позволяет пользователям добавлять произвольные данные в JSON-подобном формате к UTXO, называемые Datum. Datum позволяет разработчикам предоставлять функциональность, подобную состоянию, для скриптов, связанных с определенными UTXO.
Более того, транзакции на Cardano могут содержать параметры, относящиеся к конкретным пользователям, известным как redeemers. Redeemer позволяет инициатору транзакции определить, как будут использоваться UTXO, и может быть использован разработчиками dApp для различных целей.
Когда транзакция проходит проверку, сценарий проверки работает с использованием Datum, Redeemer и контекста, содержащего данные транзакции. Этот скрипт включает в себя логику использования UTXO при выполнении определенных условий.
Стоит отметить, что eUTXO по-прежнему выполняет задачи расширения с помощью скриптов и значительно отличается от традиционного понятия "смарт-контрактов" (Чарльз Хоскинсон, основатель, предлагает называть его "программируемым валидатором", но термин "смарт-контракты" более широко распространен на рынке).
В Nervos (CKB) значение состояния абстрагируется TypeScript, а право собственности на состояние абстрагируется локскриптом. Простая модель оптимизации UTXO в виде клеточного кода выглядит следующим образом:
pub struct CellOutput {
Вместимость паба: Capacity,
pub data: Vec<u8>,
pub lock: Script,
pub type_: Option<Script>,
}
Что касается вопроса о соперничестве состояний, то в настоящее время CKB проводит исследования в области Открытых транзакций, где пользователи могут предложить частичный UTXO с указанием цели транзакции, а затем матчмейкеры объединяют их в полную транзакцию.
Клеточная модель Nervos - это "обобщенная" версия UTXO, и Ян дал подробное объяснение на форуме Nervos:
Основное внимание в Layer1 уделяется состоянию, а поскольку Layer1 является целью проектирования, CKB, естественно, фокусируется на состоянии.
Ethereum разделяет историю транзакций и историю состояний на два измерения, где блоки и транзакции представляют события, вызывающие переходы состояний, а не сами состояния. В отличие от этого, протокол Bitcoin объединяет транзакции и состояния в одно измерение: транзакции - это состояние, а состояние - это транзакция. Это архитектура, сосредоточенная вокруг государства.
В то же время CKB стремится проверять и сохранять не только nValue как состояние, но и любые данные, которые будут сочтены ценными и одобрены консенсусом для долгосрочного хранения. Структура вывода транзакций Биткойна не подходит для этой цели, но она дала нам достаточно вдохновения. Обобщив nValue и превратив его из пространства, хранящего целые числа, в пространство, способное хранить любые данные, мы получим более обобщенный "CTxOut" или Cell.
В ячейке nValue становится двумя полями: емкость и данные. Эти поля совместно представляют собой пространство для хранения данных, где емкость - это целое число, указывающее на размер пространства в байтах, а данные - это место, где хранится состояние, которое может содержать любую последовательность байтов. ScriptPubKey становится блокировкой, просто меняя имя, выражая, кто является владельцем этого пространства консенсуса - только тот, кто может предоставить параметры (например, подпись) для успешного выполнения скрипта блокировки, может "обновить" состояние в этой Ячейке. Общее количество байт, занимаемых всей CellOutput, должно быть меньше или равно емкости. У CKB есть множество ячеек, и их коллекция формирует полное текущее состояние CKB, хранящего общие знания, а не просто конкретную цифровую валюту.
Транзакции по-прежнему представляют собой изменения/перемещения состояния. Изменение состояния или "обновление" содержимого ячейки на самом деле происходит через разрушение и создание (а не путем прямого изменения содержимого исходной ячейки). Каждая транзакция эффективно уничтожает партию клеток и одновременно создает новую партию клеток. Вновь созданные ячейки имеют новых владельцев и хранят новые данные, но общая уничтоженная емкость всегда больше или равна общей созданной емкости, что гарантирует, что никто не сможет произвольно увеличить емкость. Поскольку мощность может быть передана, но не может быть произвольно увеличена, обладание мощностью эквивалентно владению соответствующим объемом пространства состояний консенсуса. Мощность - это основной актив в сети CKB. Уничтожение ячейки просто помечает ее как "уничтоженную", подобно тому, как неизрасходованные Bitcoin UTXO становятся потраченными и не удаляются физически из блокчейна. Каждая ячейка может быть уничтожена только один раз, так же как и каждый UTXO может быть потрачен только один раз.
Характеристики этой модели следующие:
Государство имеет первостепенное значение.
Владение - это атрибут государства, причем у каждого государства есть единственный владелец.
Государства постоянно разрушаются и создаются.
Таким образом, ячейка - это обобщенная версия UTXO.
Fuel использует модель Strict Access List, которая представляет собой оптимизацию UTXO, основанную на концепции Contract UTXO.
Как было показано ранее, традиционный UTXO в BTC имеет только два атрибута: количество монет и их владелец. В отличие от этого, контракт UTXO предоставляет дополнительные фундаментальные свойства, включая количество монет, идентификатор контракта, хэш-код контракта и корень хранения.
Если используется модель выполнения без статического состояния, только Contract UTXO требует хэша кода контракта и корня хранения. В модели выполнения с состоянием эти поля можно опустить в Contract UTXO, но для этого потребуется отдельный тип Storage Element UTXO. UTXO ID, уникальный идентификатор для каждого UTXO, служащий ключом в базе данных хранения ключевых значений, генерируется из точки выхода UTXO или ее варианта (например, хэш точки выхода и ее полей).
В этой модели контракт UTXO, подобно смарт-контрактам, может быть вызван кем угодно.
Важно отметить, что Fuel обеспечивает функциональность, близкую к смарт-контрактам, а не к скриптам. Ограничения самой модели UTXO делают разработку приложений с помощью ВМ сложной, особенно при решении проблем с UTXO. Как правило, существует три решения: первое - обработка вне цепи, например, в rollup; второе - предварительная последовательность дополнительной работы, которую использует Fuel; третье - вышеупомянутая Открытая транзакция в CKB, где каждый пользователь может предлагать частичные транзакции, а специалист по согласованию (подобно секвенсору) объединяет их в полные транзакции. Соответствующее решение в BTC - PBST.
Заключение
Из этой статьи мы поняли фундаментальные принципы работы UTXO, осознали сильные и слабые стороны ее модели по сравнению с моделью счета/баланса Ethereum, а также получили более четкое представление о концепции UTXO и связанных с ней расширениях.
Будучи одним из основных принципов разработки Биткойна, модель UTXO играет важнейшую роль в обеспечении безопасности и отслеживаемости транзакций. С постоянным развитием и расширением технологии блокчейн развивается модель UTXO (например, EUTXO, cell, Strict Access List), предоставляя больше возможностей для транзакций и управления цифровыми активами. Благодаря глубокому изучению и пониманию концепции UTXO и связанных с ней расширений, мы сможем лучше понять суть технологии блокчейн, заложив более прочный фундамент для будущих инноваций и приложений.
Будучи одним из основных принципов дизайна Биткойна, модель UTXO стала важной технической парадигмой в области блокчейна с момента его создания. Она играет важнейшую роль в обеспечении безопасности и отслеживании транзакций, предоставляя альтернативный путь за пределы традиционной модели баланса счета. С непрерывным развитием и расширением технологии блокчейн в последние годы, сама модель UTXO постоянно эволюционирует и расширяется, например, eUTXO, cell, Strict access list и другие.
Эта статья знакомит с моделью UTXO на простом языке, давая краткий обзор модели UTXO и методов ее реализации в BTC, Sui, Cardano, Nervos и Fuel.
Чтобы проиллюстрировать модель 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 косвенно способствовали появлению "Ethereum". Виталик, один из самых первых авторов журнала Bitcoin Magazine, хорошо знал о недостатках Биткойна. Модель "счет/баланс", которая проще для понимания большинства людей, решает проблемы, с которыми сталкивается UTXO при работе с приложениями с богатым состоянием. Как заявил Виталик в техническом описании Ethereum:
UTXO может быть либо потрачен, либо не потрачен; здесь нет возможности для многоступенчатых контрактов или скриптов, которые сохраняют любое другое внутреннее состояние, помимо этого. Это затрудняет создание многоступенчатых опционных контрактов, децентрализованных предложений обмена или двухступенчатых криптографических протоколов обязательств (необходимых для безопасных вычислительных баунти). Это также означает, что UTXO можно использовать только для создания простых, одноразовых контрактов, а не более сложных "государственных" контрактов, таких как децентрализованные организации, и затрудняет реализацию мета-протоколов. Бинарное состояние в сочетании с "слепотой значений" также означает невозможность другого важного применения - лимитов на вывод средств.
Прежде чем перейти к рассмотрению различных применений и оптимизаций модели UTXO, давайте проанализируем области, требующие улучшения при сохранении ее преимуществ. Вкратце их можно описать следующим образом:
Абстрагирование значения состояния, хранящегося в UTXOs.
Абстрагирование права собственности на государство.
Решение проблем, связанных с содержанием, при совместном использовании UTXO.
В BTC единственным значением состояния является количество токенов, право собственности обычно определяется с помощью публичных ключей, а проблема спора состояний не рассматривается в широком смысле, поскольку BTC не был разработан для dApps.
Sui предоставляет разработчикам два типа объектов: OwnedObject и SharedObject. Первая похожа на UTXO (в частности, на расширенную версию), а вторая сравнима с моделью "счет/баланс". Оба могут использоваться одновременно.
Объект может быть общим, то есть любой может читать или писать в этот объект. В отличие от мутабельного OwnedObject (с одним писателем), SharedObject требует консенсуса для упорядочивания чтения и записи.
В других блокчейнах каждый Объект является общим. Однако разработчики Sui обычно могут выбрать использование OwnedObject, SharedObject или комбинацию обоих вариантов для реализации конкретных случаев использования. Этот выбор может повлиять на производительность, безопасность и сложность реализации.
В Sui объекты, находящиеся в собственности, похожи на UTXO, и только их владелец может оперировать ими. Объекты также имеют номера версий, и одна версия объекта может быть потрачена его владельцем только один раз. Таким образом, версия объекта по сути соответствует UTXO.
Что касается проблем, связанных с контролем состояния, Sui решает их с помощью специальной обработки (локальное упорядочивание, аналогичное Fuel) в SharedObjects.
В Cardano используется расширенная модель UTXO, известная как eUTXO. eUTXO поддерживает повышенную программируемость, сохраняя при этом преимущества модели Bitcoin UTXO.
В Cardano значение государства еще больше расширяется с помощью скриптов, а право собственности на государство определяется более обобщенно. Наборы UTXO используются, чтобы минимизировать проблемы, связанные с контролем состояния. В частности, eUTXO усовершенствован в двух аспектах:
Модель eUTXO включает в себя более обобщенные адреса. Эти адреса основаны не только на хэше открытых ключей, но могут быть определены на основе любой логики, определяющей условия, при которых eUTXO могут быть потрачены, что позволяет программировать государственную собственность.
Помимо адресов и значений, выходы могут нести (почти) любые данные, что позволяет программировать значение состояния с помощью скриптов.
Более конкретно, eUTXO позволяет пользователям добавлять произвольные данные в JSON-подобном формате к UTXO, называемые Datum. Datum позволяет разработчикам предоставлять функциональность, подобную состоянию, для скриптов, связанных с определенными UTXO.
Более того, транзакции на Cardano могут содержать параметры, относящиеся к конкретным пользователям, известным как redeemers. Redeemer позволяет инициатору транзакции определить, как будут использоваться UTXO, и может быть использован разработчиками dApp для различных целей.
Когда транзакция проходит проверку, сценарий проверки работает с использованием Datum, Redeemer и контекста, содержащего данные транзакции. Этот скрипт включает в себя логику использования UTXO при выполнении определенных условий.
Стоит отметить, что eUTXO по-прежнему выполняет задачи расширения с помощью скриптов и значительно отличается от традиционного понятия "смарт-контрактов" (Чарльз Хоскинсон, основатель, предлагает называть его "программируемым валидатором", но термин "смарт-контракты" более широко распространен на рынке).
В Nervos (CKB) значение состояния абстрагируется TypeScript, а право собственности на состояние абстрагируется локскриптом. Простая модель оптимизации UTXO в виде клеточного кода выглядит следующим образом:
pub struct CellOutput {
Вместимость паба: Capacity,
pub data: Vec<u8>,
pub lock: Script,
pub type_: Option<Script>,
}
Что касается вопроса о соперничестве состояний, то в настоящее время CKB проводит исследования в области Открытых транзакций, где пользователи могут предложить частичный UTXO с указанием цели транзакции, а затем матчмейкеры объединяют их в полную транзакцию.
Клеточная модель Nervos - это "обобщенная" версия UTXO, и Ян дал подробное объяснение на форуме Nervos:
Основное внимание в Layer1 уделяется состоянию, а поскольку Layer1 является целью проектирования, CKB, естественно, фокусируется на состоянии.
Ethereum разделяет историю транзакций и историю состояний на два измерения, где блоки и транзакции представляют события, вызывающие переходы состояний, а не сами состояния. В отличие от этого, протокол Bitcoin объединяет транзакции и состояния в одно измерение: транзакции - это состояние, а состояние - это транзакция. Это архитектура, сосредоточенная вокруг государства.
В то же время CKB стремится проверять и сохранять не только nValue как состояние, но и любые данные, которые будут сочтены ценными и одобрены консенсусом для долгосрочного хранения. Структура вывода транзакций Биткойна не подходит для этой цели, но она дала нам достаточно вдохновения. Обобщив nValue и превратив его из пространства, хранящего целые числа, в пространство, способное хранить любые данные, мы получим более обобщенный "CTxOut" или Cell.
В ячейке nValue становится двумя полями: емкость и данные. Эти поля совместно представляют собой пространство для хранения данных, где емкость - это целое число, указывающее на размер пространства в байтах, а данные - это место, где хранится состояние, которое может содержать любую последовательность байтов. ScriptPubKey становится блокировкой, просто меняя имя, выражая, кто является владельцем этого пространства консенсуса - только тот, кто может предоставить параметры (например, подпись) для успешного выполнения скрипта блокировки, может "обновить" состояние в этой Ячейке. Общее количество байт, занимаемых всей CellOutput, должно быть меньше или равно емкости. У CKB есть множество ячеек, и их коллекция формирует полное текущее состояние CKB, хранящего общие знания, а не просто конкретную цифровую валюту.
Транзакции по-прежнему представляют собой изменения/перемещения состояния. Изменение состояния или "обновление" содержимого ячейки на самом деле происходит через разрушение и создание (а не путем прямого изменения содержимого исходной ячейки). Каждая транзакция эффективно уничтожает партию клеток и одновременно создает новую партию клеток. Вновь созданные ячейки имеют новых владельцев и хранят новые данные, но общая уничтоженная емкость всегда больше или равна общей созданной емкости, что гарантирует, что никто не сможет произвольно увеличить емкость. Поскольку мощность может быть передана, но не может быть произвольно увеличена, обладание мощностью эквивалентно владению соответствующим объемом пространства состояний консенсуса. Мощность - это основной актив в сети CKB. Уничтожение ячейки просто помечает ее как "уничтоженную", подобно тому, как неизрасходованные Bitcoin UTXO становятся потраченными и не удаляются физически из блокчейна. Каждая ячейка может быть уничтожена только один раз, так же как и каждый UTXO может быть потрачен только один раз.
Характеристики этой модели следующие:
Государство имеет первостепенное значение.
Владение - это атрибут государства, причем у каждого государства есть единственный владелец.
Государства постоянно разрушаются и создаются.
Таким образом, ячейка - это обобщенная версия UTXO.
Fuel использует модель Strict Access List, которая представляет собой оптимизацию UTXO, основанную на концепции Contract UTXO.
Как было показано ранее, традиционный UTXO в BTC имеет только два атрибута: количество монет и их владелец. В отличие от этого, контракт UTXO предоставляет дополнительные фундаментальные свойства, включая количество монет, идентификатор контракта, хэш-код контракта и корень хранения.
Если используется модель выполнения без статического состояния, только Contract UTXO требует хэша кода контракта и корня хранения. В модели выполнения с состоянием эти поля можно опустить в Contract UTXO, но для этого потребуется отдельный тип Storage Element UTXO. UTXO ID, уникальный идентификатор для каждого UTXO, служащий ключом в базе данных хранения ключевых значений, генерируется из точки выхода UTXO или ее варианта (например, хэш точки выхода и ее полей).
В этой модели контракт UTXO, подобно смарт-контрактам, может быть вызван кем угодно.
Важно отметить, что Fuel обеспечивает функциональность, близкую к смарт-контрактам, а не к скриптам. Ограничения самой модели UTXO делают разработку приложений с помощью ВМ сложной, особенно при решении проблем с UTXO. Как правило, существует три решения: первое - обработка вне цепи, например, в rollup; второе - предварительная последовательность дополнительной работы, которую использует Fuel; третье - вышеупомянутая Открытая транзакция в CKB, где каждый пользователь может предлагать частичные транзакции, а специалист по согласованию (подобно секвенсору) объединяет их в полные транзакции. Соответствующее решение в BTC - PBST.
Заключение
Из этой статьи мы поняли фундаментальные принципы работы UTXO, осознали сильные и слабые стороны ее модели по сравнению с моделью счета/баланса Ethereum, а также получили более четкое представление о концепции UTXO и связанных с ней расширениях.
Будучи одним из основных принципов разработки Биткойна, модель UTXO играет важнейшую роль в обеспечении безопасности и отслеживаемости транзакций. С постоянным развитием и расширением технологии блокчейн развивается модель UTXO (например, EUTXO, cell, Strict Access List), предоставляя больше возможностей для транзакций и управления цифровыми активами. Благодаря глубокому изучению и пониманию концепции UTXO и связанных с ней расширений, мы сможем лучше понять суть технологии блокчейн, заложив более прочный фундамент для будущих инноваций и приложений.