UTXO vs. Account vs. Object: Скрытая война, формирующая кроссчейн-архитектуру

Когда разработчики Ethereum пытаются строить на Sui, происходит нечто странное. Ментальная модель рушится. Переменные не хранятся в смарт-контрактах. Состояние находится не там, где вы ожидаете. Активы перемещаются иначе. И когда мосты пытаются соединить Bitcoin с Ethereum или Ethereum с Sui, инженеры сталкиваются с проблемой, которая глубже протокольных различий — они пытаются согласовать три фундаментально несовместимые теории того, чем вообще является «транзакция».

Это не просто второстепенная деталь реализации. Выбор между моделями транзакций UTXO, Account и Object — одно из самых значимых архитектурных решений в дизайне блокчейна. Он определяет всё: как валидируются транзакции, как работает параллелизация, как достигается конфиденциальность и — что наиболее критично в 2026 году — как различные блокчейн-сети вообще могут взаимодействовать друг с другом.

Три модели, три философии

Модель UTXO: Учет как наличные

Модель остатка неизрасходованных выходов транзакций (UTXO) в Bitcoin является старейшей из трех и самой философски чистой. В этой модели нет «аккаунтов» в традиционном понимании. Вместо этого существуют выходы — дискретные единицы стоимости, созданные предыдущими транзакциями и потребляемые новыми.

Представьте это как наличные деньги. Когда вы получаете платеж, вы держите конкретную купюру. Когда вы ее тратите, эта купюра уничтожается и создаются новые — одна отправляется получателю, другая возвращается вам в виде сдачи. Каждую купюру можно потратить только один раз. Реестр отслеживает купюры, а не балансы.

Такой дизайн имеет глубокие последствия:

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

Параллелизация через независимость. Транзакции UTXO, которые не имеют общих входных данных, могут валидироваться одновременно. Сеть Bitcoin может обрабатывать независимые транзакции параллельно, так как нет общего состояния, которое нужно защищать. При скорости примерно 7–15 транзакций в секунду Bitcoin не является самой быстрой сетью, но эти транзакции теоретически могут валидироваться параллельно.

Детерминизм и аудит. Полную историю транзакций можно проверить с момента генезиса. Здесь нет скрытых переходов состояний — каждый UTXO имеет доказуемую цепочку владения.

Компромисс? Страдает выразительность смарт-контрактов. Системы UTXO блестяще моделируют передачу стоимости, но с трудом справляются с сложной логикой состояния. Расширенная модель UTXO (eUTXO) в Cardano пытается решить эту проблему, позволяя UTXO нести произвольные данные, но парадигма программирования остается принципиально отличной от подхода Ethereum.

Модель Account: Состояние как база данных

Модель аккаунтов (Account) в Ethereum использует противоположный подход. Вместо отслеживания отдельных монет она поддерживает глобальную базу данных состояния с балансами аккаунтов и хранилищами контрактов. Когда вы отправляете ETH, баланс вашего аккаунта уменьшается, а баланс получателя увеличивается — как при банковском переводе, а не при обмене наличными.

Эта модель сделала программируемые деньги интуитивно понятными. Разработчики на Solidity мыслят категориями переменных и функций, а не происхождением монет. Модель аккаунтов обеспечила взрывной рост DeFi: AMM, протоколы кредитования, контракты стейкинга — все они требуют чтения и записи общего состояния, с чем модель аккаунтов справляется естественно.

Однако модель аккаунтов несет в себе фундаментальную проблему параллелизации. Поскольку несколько транзакций могут одновременно обращаться к одному и тому же аккаунту, сеть не может безопасно выполнять их параллельно, не зная заранее, какое состояние изменит каждая транзакция. Ethereum обрабатывает около 30 транзакций в секунду на базовом уровне — не из-за ограничений вычислительной мощности, а потому, что последовательные переходы состояний архитектурно необходимы для корректности.

Подход EVM к этому прямолинеен: транзакции выполняются последовательно в том порядке, в котором они появляются в блоке. Существуют попытки оптимистичной параллелизации (L2-решения Ethereum, такие как Monad), но они должны обрабатывать конфликты путем повторного выполнения неудачных транзакций, что создает накладные расходы, ограничивающие теоретический рост пропускной способности.

Штраф за конфиденциальность. Адреса аккаунтов постоянны и полностью прослеживаемы. Каждая транзакция с одного и того же адреса может быть связана с другими. Конфиденциальность в Ethereum требует дополнительных уровней — миксеров, ZK-доказательств, стелс-адресов — именно потому, что дизайн модели аккаунтов раскрывает весь граф транзакций.

Модель Object: Явное владение, явные зависимости

Объектная модель (Object) в Sui, построенная на языке программирования Move, представляет собой новейшую парадигму. Вместо аккаунтов с балансами (модель Account) или цепочек монет (UTXO), всё в Sui является объектом: уникальным, типизированным ресурсом, имеющим владельца и явную цепочку владения.

Монеты — это объекты. NFT — это объекты. Возможности смарт-контрактов — это объекты. И что критически важно, каждая транзакция явно объявляет, к каким объектам она будет обращаться, включая то, требуется ли ей эксклюзивное владение или просто общий доступ.

Эта явность решает проблему параллелизации, которой страдает модель аккаунтов. Поскольку транзакции заранее объявляют свои зависимости, сеть валидаторов может немедленно увидеть, какие транзакции независимы, и выполнять их одновременно. Транзакции с объектами, принадлежащими одному владельцу, могут полностью обходить консенсус, обеспечивая сверхнизкую задержку. Транзакции с общими объектами проходят через консенсус, но все равно выигрывают от изоляции на уровне объектов.

Результат: Sui нацелена на 297 000 транзакций в секунду в тестах, хотя реальная производительность сильно зависит от состава транзакций. Aptos использует другой подход — Block-STM, механизм оптимистичного параллельного выполнения, который достигает аналогичных целей, спекулятивно выполняя все транзакции параллельно и откатывая конфликты. В 2025 году Aptos продемонстрировал теоретическую пропускную способность, приближающуюся к 1 миллиону TPS на бесконфликтных рабочих нагрузках.

Объектная модель также улучшает компонуемость для определенных паттернов. Протокол DeFi, хранящий балансы пользователей в модели аккаунтов, должен тщательно управлять атаками повторного входа (reentrancy) — проблемой общего состояния. Протоколы на объектной модели владеют дискретными активами, что делает определенные векторы атак структурно невозможными.

Проблема кроссчейн-перевода

Вот где инженерные задачи становятся по-настоящему сложными. Когда пользователь хочет переместить активы между Bitcoin, Ethereum и Sui, он просит инфраструктуру моста осуществить перевод между тремя несовместимыми реальностями:

Свойство	UTXO (Bitcoin)	Аккаунт (Ethereum)	Объект (Sui / Aptos)
Единица состояния	Неизрасходованный выход	Баланс аккаунта	Владеемый объект
Идентификация	Ссылка на выход	Адрес	ID объекта
Смарт-контракты	Ограничены	Развитые	Развитые (Move)
Параллелизация	Естественная	Сложная	Заложена в архитектуру
Конфиденциальность	Нативная	Требует дополнений	На уровне объектов
Предотвращение двойных трат	Уникальность UTXO	На основе nonce	Владение объектом

Разрыв между UTXO и аккаунтами — это старейшая и наиболее изученная проблема. Когда вы переносите Bitcoin в Ethereum (обернутый BTC), вы создаете долговую расписку (IOU) — мост блокирует реальный BTC в UTXO в сети Bitcoin и выпускает эквивалентный токен ERC-20 в Ethereum. Технический идентификатор ваших активов полностью меняется. Ссылка на UTXO в Bitcoin не имеет смысла в модели аккаунтов Ethereum; мост должен поддерживать отдельное сопоставление.

Этот перевод создает поверхности для атак. Хранение на стороне Bitcoin (мультисиг или смарт-контракт, управляющий UTXO) работает на совершенно иных принципах, чем логика выпуска на стороне Ethereum. Сбои в системе безопасности на любом уровне могут привести к каскадным последствиям. Крупнейшие эксплойты мостов на сумму более 600 млн долларов в 2021–2023 годах во многом стали результатом несовершенной реализации этого слоя перевода.

Разрыв между аккаунтами и объектами — проблема более новая, но не менее сложная. Когда активы Ethereum перемещаются в Sui, адрес Ethereum не сопоставляется напрямую с объектом Sui. Модель владения Sui требует, чтобы активы имели явных, отслеживаемых владельцев с проверяемыми ссылками на объекты. Мосты должны синтезировать идентичность объектов на основе учетных данных модели аккаунтов — это перевод с потерей данных, требующий тщательного проектирования протокола.

Архитектура обмена сообщениями LayerZero решает эту проблему, работая на уровне сообщений, а не на уровне активов: её ультралегкие узлы (Ultra Light Nodes) подтверждают, что «что-то произошло в сети А», без необходимости полностью понимать модель транзакций сети А. Когда в 2025 году LayerZero добавила поддержку Cardano, подключив её к более чем 160 сетям, инженерной команде пришлось обрабатывать семантику eUTXO на стороне Cardano, сохраняя при этом привычные для Ethereum абстракции в других местах.

Перевод UTXO в объекты, пожалуй, является самым сложным. Происхождение монет в Bitcoin и происхождение объектов в Sui — это модели явного владения, но детали расходятся настолько сильно, что простой перевод не работает. UTXO в Bitcoin не имеет «идентичности» владельца в традиционном понимании — владение доказывается криптографической подписью. Объекты Sui содержат явные поля владения. Мост должен переводить владение на основе доказательств во владение на основе полей, сохраняя возможность аудита в обеих системах.

Взаимодействие моделей консенсуса

Выбор модели транзакций влияет на проектирование механизмов консенсуса способами, которые усиливают эти несовместимости.

Модель UTXO в Bitcoin естественным образом сочетается с консенсусом Proof-of-Work: майнеры проверяют независимые UTXO в любом порядке их появления, а канонический порядок цепочки определяется постфактум накопленной мощностью хеширования. Нет необходимости предварительно упорядочивать транзакции для последовательного автомата состояний.

Модель аккаунтов Ethereum требует заранее определенного порядка транзакций (упорядочивание в мемпуле, обеспечиваемое валидаторами) для предотвращения конфликтов состояний. Именно поэтому проблема MEV (Maximal Extractable Value) в Ethereum стоит так остро — сам порядок транзакций имеет финансовую ценность, и валидаторы могут извлекать её, переупорядочивая транзакции в свою пользу.

Sui и Aptos используют варианты консенсуса Byzantine Fault Tolerant (BFT), специально разработанные для работы с их объектно-ориентированными моделями выполнения. Транзакции с объектами, имеющими одного владельца, в Sui используют упрощенный путь консенсуса (называемый fastpath или прямая финализация), который обеспечивает задержку в несколько сотен миллисекунд — на уровне централизованных платежных систем. Транзакции с общими объектами используют полный консенсус BFT, но даже здесь изоляция на уровне объектов снижает сложность автомата состояний.

Когда мостам необходимо проверять финализацию в этих различных моделях консенсуса, инженерная задача усложняется многократно. ZK-мост, проверяющий транзакцию Bitcoin UTXO, должен доказать, что транзакция появилась в блоке с достаточной глубиной PoW. Тот же мост, проверяющий обновление состояния аккаунта Ethereum, должен доказать, что корень состояния соответствует правильному блоку, финализированному через BFT. А проверка перехода объекта Sui требует валидации в соответствии с DAG-консенсусом Mysticeti. Это три отдельные задачи криптографической проверки, которые должны быть объединены в единый аргумент безопасности.

Последствия для разработчиков в 2026 году

Для разработчиков, выбирающих платформу для создания проектов в 2026 году, модель транзакций должна быть основным фактором, а не второстепенной деталью.

Создавайте на сетях с моделью UTXO (Bitcoin, Cardano), если:

• Ваше приложение — это прежде всего передача ценности с минимальными переходами состояний.
• Конфиденциальность является первоочередным требованием.
• Долгосрочная проверяемость и отслеживаемость имеют важное значение.
• Вы строите решения второго уровня (Layer 2), которые привязывают безопасность к Proof-of-Work сети Bitcoin.

Создавайте на сетях с моделью аккаунтов (Ethereum, BNB Chain, Avalanche), если:

• Вашему приложению требуется сложное общее состояние (AMM, протоколы кредитования, DAO).
• Экосистема разработчиков и глубина инструментария важнее всего.
• Вам нужна самая широкая поверхность взаимодействия с DeFi (composability).
• Институциональное знакомство с примитивами Ethereum является обязательным требованием.

Создавайте на сетях с объектной моделью (Sui, Aptos), если:

• Пропускная способность транзакций и задержка являются критическими требованиями.
• Ваше приложение имеет естественным образом независимые состояния (игровые предметы, операции с NFT).
• Вы проектируете явные потоки владения активами.
• Преимущества параллелизации могут быть использованы за счет тщательного проектирования модели данных.

Тенденция 2025–2026 годов заключается в том, что разработчики строят проекты одновременно в нескольких сетях — это делает проблему кроссчейн-перевода не просто вопросом инфраструктуры, а вопросом архитектуры приложений. То, как вы представляете состояние в сети А, определяет, как это состояние может быть представлено в сети B.

Что это значит для инфраструктуры

Кроссчейн-инфраструктура в 2026 году стремительно развивается, но фундаментальная проблема трансляции не была решена — она была абстрагирована. Протоколы, такие как LayerZero, Axelar и Hyperlane, предоставляют уровни обмена сообщениями, которые работают в моделях UTXO, Account и Object. Технология ZK-мостов обеспечивает бездоверительную верификацию кроссчейн-событий без необходимости в доверенном посреднике для интерпретации модели транзакций каждой сети.

Однако у абстракции есть своя цена. Каждый уровень трансляции добавляет задержки, определенные допущения безопасности и потенциальные точки отказа. Наиболее эффективные приложения часто разрабатываются так, чтобы минимизировать кроссчейн-зависимости — используя каждую сеть для того, с чем её модель транзакций справляется лучше всего, и прибегая к мостам только в случае необходимости.

Более глубокое понимание заключается в том, что «интероперабельность блокчейнов» — это не одна инженерная задача. Это целое семейство проблем, каждая из которых определяется моделями транзакций по обе стороны моста. Мосты UTXO-to-Account сталкиваются с иными вызовами, чем мосты Account-to-Object. И любой протокол, заявляющий об универсальном решении проблемы интероперабельности, должен оцениваться с учетом этой специфической сложности.

С запуском сети Zero от LayerZero осенью 2026 года с её архитектурой гетерогенных зон — разделяющей среды выполнения для различных рабочих нагрузок — мы видим практическое признание того, что ни одна модель транзакций не является универсальной. Будущее — за мультимодельной интероперабельностью, тщательно проработанной на каждом стыке.

---

BlockEden.xyz предоставляет RPC API корпоративного уровня для Sui, Aptos, Ethereum и более чем 40 других блокчейнов — абстрагируя сложность кроссчейн-взаимодействия, чтобы разработчики могли сосредоточиться на логике приложений, а не на трансляции моделей транзакций. Изучите наш API Marketplace, чтобы создавать решения на базе инфраструктуры, охватывающей все основные модели транзакций.