Оригинальная ссылка на английском языке: https://medium.com/nervosnetwork/my-comparison-between-the-utxo-and-account-model-821eb46691b2

В современном мире блокчейнов существует два основных метода ведения учета: модель UTXO (выход неизрасходованных транзакций) и модель учетной записи. Биткойн использует модель UTXO, а Ethereum использует модель учетной записи.

Биткойн изначально был разработан как одноранговая электронная денежная система. В Биткойне каждая транзакция потребляет UTXO, сгенерированный предыдущей транзакцией, а затем генерирует новый UTXO. Баланс счета представляет собой набор всех неизрасходованных UTXO, принадлежащих данному аккаунту. адрес. Глобальное состояние Биткойна — это совокупность всех неизрасходованных на данный момент UTXO. Ethereum намерен создать более общий протокол, поддерживающий Тьюринг-полные языки программирования, на котором пользователи смогут писать смарт-контракты и создавать различные децентрализованные приложения. Из-за недостатков модели UTXO в плане сохранения состояния и программирования, Ethereum представил модель Account.

Ниже мы более подробно остановимся на преимуществах и недостатках двух моделей.

Модель UTXO


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

преимущество:

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

  2. За исключением транзакций Coinbase, вход транзакции всегда связан с UTXO. Транзакции не могут быть воспроизведены, а последовательность и зависимости транзакций можно легко проверить, а также можно легко доказать, были ли транзакции использованы.

  3. Модель UTXO не имеет состояния и ее легче обрабатывать одновременно.

  4. Улучшенная конфиденциальность для транзакций типа P2SH. Входные данные транзакции не связаны друг с другом, и такие технологии, как CoinJoin, можно использовать для повышения определенной степени конфиденциальности.

недостаток:

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

  2. Когда входных данных будет больше, количество сценариев-свидетелей также увеличится. Сама подпись потребляет больше ресурсов ЦП и места для хранения.

Модель аккаунта

Для модели Account модель Account сохраняет мировое состояние, а состояние цепочки обычно согласовывается в форме StateRoot и ReceiptRoot в блоке. Транзакция — это всего лишь само событие и не содержит результата. Консенсус транзакции и консенсус состояния могут быть существенно изолированы.

преимущество:

  1. Контракт хранится в Account в виде кода, а Account имеет собственное состояние. Эта модель лучше программируется, ее легче понять разработчикам и она имеет более широкий спектр сценариев.

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

недостаток:

  1. Между транзакциями модели учетной записи нет зависимости, и необходимо решить проблему воспроизведения.

  2. Для реализации Lightning Network/Thunder Network, Plasma и т. д. для подтверждения пользователя требуется более сложный механизм Proof-доказательства, а для миграции состояния из подцепей в основную цепочку требуется более сложный протокол.

UTXO против аккаунта

Давайте проведем некоторый анализ и сравнение вышеуказанных преимуществ и недостатков.

Во-первых, что касается вопросов расчета

Сама по себе транзакция UTXO не имеет сложных вычислений для блокчейна. Проще говоря, она не совсем точна. Во-первых, большинство собственных транзакций Биткойна являются P2SH, а сценарий Witness не является полным по Тьюрингу и не является таковым. существует оператор цикла. Для модели учетной записи, такой как Ethereum, поскольку большая часть вычислений выполняется в цепочке и является полной по Тьюрингу, вычисления, как правило, более сложны, и безопасность контракта может легко стать относительно большой проблемой. Конечно, то, является ли она полной по Тьюрингу или нет, не имеет прямого отношения к тому, является ли она моделью учетной записи. Но после внедрения модели аккаунта контракт может существовать как самостоятельная сущность, никем не контролируемая, что имеет большое значение.

Во-вторых, что касается проблемы упрощения параллелизма UTXO.

В модели UTXO состояние мира представляет собой набор UTXO. Чтобы быстрее проверять транзакции, узлам необходимо хранить индексы всех UTXO в памяти, поэтому UTXO очень дороги. UTXO, которые не используются в течение длительного времени, всегда будут занимать память узла. Следовательно, для этой модели теоретически следует поощрять пользователей производить меньше UTXO и потреблять больше UTXO. Однако, если вы хотите использовать UTXO для параллельных транзакций, вам нужно больше UTXO в качестве входных данных, и в то же время вам нужно генерировать больше UTXO для обеспечения параллелизма. По сути, это пылевая атака на сеть. А поскольку транзакции создаются внутри кошелька, требуется более сложная конструкция кошелька. Оглядываясь назад на модель учетной записи, можно сказать, что каждую учетную запись можно рассматривать как отдельный конечный автомат, который не влияет друг на друга, и учетные записи общаются посредством сообщений. Следовательно, теоретически, когда пользователь инициирует несколько транзакций, и эти транзакции не вызывают друг друга с одной и той же учетной записью, транзакции могут выполняться одновременно.

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

Ethereum использует метод добавления nonce в учетную запись. Каждая транзакция соответствует nonce, и nonce увеличивается каждый раз. Хотя этот метод предназначен для решения проблемы воспроизведения, он также приводит к последовательным проблемам и делает транзакции невозможными для распараллеливания. Например, в Ethereum пользователь отправляет несколько транзакций. Если первая транзакция не может быть упакована, последующие транзакции не будут упакованы успешно. В CITA мы используем случайную схему nonce, чтобы не было последовательной зависимости между пользовательскими транзакциями, что не приведет к последовательному сбою, а также дает возможность параллельной обработки транзакций.

В-четвёртых, проблемы с хранением.

Потому что в модели UTXO состояние может сохраняться только в транзакциях. Состояние модели учетной записи сохраняется в узле и хранится с использованием MPT в Ethereum. В блоке требуется только консенсус StateRoot. Таким образом, для данных в цепочке модель учетной записи фактически меньше, а объем сетевой передачи меньше. В то же время состояние сохраняется локально на узле с использованием MPT, что более эффективно в использовании пространства. Например, если A переводит деньги B, если в UTXO есть 2 входа и 2 выхода, в модели Account требуются 2 скрипта-свидетеля и 2 скрипта блокировки, требуется только одна подпись, а содержимое транзакции содержит только сумму; . После внедрения последней версии Segregated Witness объем данных транзакций Биткойн также значительно сократился, но на самом деле узлам проверки и полным узлам по-прежнему необходимо передавать и проверять сценарий Witness.

В-пятых, для легких узлов получение определенного статуса адреса UTXO более сложен.

Например, в кошельке вам необходимо запросить все UTXO по определенному адресу у полного узла. Полный узел может отправить несколько UTXO. Кошелю сложно проверить, был ли использован UTXO, и это сложно для него. кошелек, чтобы доказать, что UTXO — это полный набор, а не частичная коллекция. Модель учетной записи намного проще. Соответствующее состояние в State находится на основе адреса. State Доказательство текущего состояния может подтвердить подлинность данных контракта. Конечно, для UTXO корень UTXO также можно проверить в каждом блоке. Это связано с текущей реализацией Биткойна и не является особенностью UTXO.


в заключение

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