Перевод статьи https://cexplorer.io/article/how-the-accounting-model-and-design-of-the-blockchain-affects-scalability
Cardano использует модель UTxO, и только небольшие скрипты проверяются ончейн. Ethereum использует аккаунт-модель, и вся логика приложения реализована в смарт контрактах. Давайте рассмотрим, как эти различные подходы влияют на параметры масштабируемости.
Масштабируемость зависит от ресурсов
Масштабируемость зависит от компьютерных ресурсов, которые обеспечивают работу сети. Блокчейн платформы - это глобальные децентрализованные сети, состоящие из большого количества нод, управляемых добровольцами. Это единственные вычислительные ресурсы, доступные сети. Для достижения высокой масштабируемости необходимо использовать эти ресурсы как можно эффективнее. Тему затрат и вознаграждений можно было бы рассмотреть отдельно.
Платформы позволяют не только передавать ценности, но и выполнять сложные операции (смарт контракты). При проектировании платформы необходимо подумать о том, как реализовать отдельные функции сети таким образом, чтобы они потребляли как можно меньше ресурсов.
Блокчейн сеть нуждается в следующих ресурсах:
- Вычислительная мощность (CPU) для выполнения вычислений и выполнения инструкций. Стандартные транзакции обычно потребляют меньше вычислительной мощности, чем выполнение смарт контрактов.
- Пространство для хранения важно для хранения данных и информации. Необходимо постоянно хранить весь блокчейн. Нодам также необходимо временно хранить данные для проверки транзакций и выполнения смарт контрактов (например, набор UTxO, распределение стейка, список активных сертификатов и т.д.).
- Пропускная способность, которая представляет собой скорость передачи данных или связи в системе.
На масштабируемость блокчейна влияют доступность, эффективность и использование упомянутых ресурсов. Хорошо масштабируемая сеть может увеличить или оптимизировать свои ресурсы для размещения большего числа пользователей, транзакций или приложений без снижения ее производительности и качества.
Отдельные приложения могут существенно отличаться друг от друга с точки зрения вычислительной мощности, объема памяти и требований к пропускной способности. Здесь имеют значение не только дизайны платформ, но и команды, которые разрабатывают и внедряют приложения.
Конструкция сети должна обеспечивать возрастающую масштабируемость за счет предоставления большего количества ресурсов, но у этого есть свои пределы. Блокчейн сети нуждаются в высокой масштабируемости, что означает возможность обрабатывать больше транзакций в секунду (TPS), но они должны поддерживать безопасность, децентрализацию и функциональность. Это большой вызов для команд.
Например, увеличение размера блока или сокращение времени создания блока может увеличить TPS, но это также увеличивает требования к хранилищу и пропускной способности нод, а также риск форков и потерянных блоков. Увеличение числа нод может повысить безопасность и децентрализацию сети, но это также увеличивает задержку и сложность механизма консенсуса.
Команды должны тщательно соблюдать баланс между всеми важными функциями блокчейн сети, помня о миссии проекта и требованиях сообщества.
Команды не должны жертвовать безопасностью и децентрализацией ради масштабируемости. Однако могут существовать проекты, для которых масштабируемость важнее децентрализации.
Сообщества ожидают от распределенных сетей таких преимуществ, как децентрализация, прозрачность и отказоустойчивость, но эти функции сопряжены с такими ограничениями, как задержка в работе сети, сложность и координация, которые являются неблагоприятными свойствами для масштабируемости.
На масштабируемость в основном влияют дизайн блокчейн сети (включая выполнение смарт контрактов) и используемая модель учета. Мы разберемся и с тем, и с другим.
В статье мы поговорим о Cardano как о платформе, использующей модель UTxO и платформу Plutus для валидации скриптов. Ethereum - это репрезентативная платформа, использующая аккаунт-модель и виртуальную машину Ethereum (EVM) для выполнения смарт контрактов.
Большинство платформ, использующих аккаунт-модель и EVM, могут иметь те же проблемы, что и Ethereum. Однако, если бы командам удалось, например, внедрить шардинг, то эти сети могли бы масштабироваться лучше, чем Ethereum. Цель статьи состоит не в том, чтобы подробно сравнить платформы смарт контрактов (SC), а в том, чтобы привлечь внимание к различиям в дизайне.
Различия между моделями учета
Модель UTXO подобна системе верификации, где каждый выход транзакции (UTxO) представляет собой цифровой актив, который может быть израсходован его владельцем.
Одним из преимуществ модели UTxO является то, что она обеспечивает больший параллелизм, что означает, что транзакции могут обрабатываться независимо и одновременно разными нодами сети, при условии, что они не расходуют одни и те же UTXO.
Это может улучшить масштабируемость и пропускную способность сети, поскольку за определенный промежуток времени может быть проверено и подтверждено большее количество транзакций. Модель UTxO также уменьшает потребность в синхронизации и координации между нодами, поскольку каждой ноде необходимо отслеживать только те UTXO, которые имеют отношение к ее транзакциям.
Модель UTxO проста и безопасна, поскольку для выполнения транзакций не требуется сложной логики или смарт контрактов. Она включает в себя только простые арифметические операции и криптографические проверки для проверки действительности и подлинности транзакций.
Недостатком модели UTxO является то, что она более подвержена фрагментации, поскольку создает множество небольших UTXO, которые могут быть распределены по разным адресам (пользователи Cardano и Bitcoin обычно имеют средства на нескольких адресах). Это может увеличить количество и размер транзакций, поскольку для выполнения запроса на расходование может потребоваться больше входов и выходов.
Модель UTxO также увеличивает требования к хранилищу и пропускной способности нод, поскольку им необходимо хранить и передавать все UTXO, имеющие отношение к их транзакциям.
Аккаунт-модель больше похожа на систему баз данных, где у каждого аккаунта есть баланс, который может обновляться с помощью транзакций. Это требует большей синхронизации и координации между нодами, поскольку транзакции должны обновлять глобальное состояние аккаунтов.
Глобальное состояние - это совокупность всех остатков на счетах и состояний в сети, которое со временем растет и должно храниться и проверяться всеми нодами.
Аккаунт-модель допускает меньший параллелизм, поскольку транзакции могут зависеть от состояния других транзакций или влиять на них. Это может снизить масштабируемость и пропускную способность сети, поскольку транзакции должны выполняться в последовательном порядке и не могут обрабатываться независимо или одновременно разными нодами.
Глобальное состояние потребляет много вычислительной мощности, поскольку оно должно быть вычислено и проверено каждой нодой. Это особенно относится к сложным или крупным транзакциям или исполнению сложных смарт контрактов. В следующем разделе я расскажу о передаче токенов и выполнении смарт контрактов.
Блокчейны, использующие модель UTxO, могут (по крайней мере, теоретически) достичь более высокой масштабируемости и пропускной способности, чем аккаунт-модель, поскольку транзакции могут проверяться параллельно. Блокчейны, использующие аккаунт-модель, могут столкнуться с узкими местами или перегрузкой из-за их зависимости от глобального состояния. Конечно, даже блокчейны, использующие аккаунт-модель, могут хорошо масштабироваться. Для этого больше подходят вторые слои (свертки, сайдчейны и т.д.).
Параллелизм полезен для масштабируемости, поскольку он может повысить производительность и качество системы за счет распределения рабочей нагрузки между несколькими нодами (более эффективное использование ресурсов, поскольку нодам не нужно простаивать). Это может увеличить скорость, пропускную способность и мощность системы, а также обеспечить большую функциональность и программируемость.
Однако параллелизм также создает новые проблемы, такие как координация и синхронизация. Рабочая нагрузка может быть распределена на несколько нод, но сеть должна обеспечивать согласованность и корректность работы системы. Даже если транзакции проверяются независимо друг от друга на разных нодах, не должно происходить двойных расходований.
Аккаунт-модель может показаться более безопасным подходом (меньшая координация и синхронизация между нодами), однако за счет неэффективности (трудно достичь высокой масштабируемости). Проблема в том, что необходимо устранять недостатки, которые в конечном итоге в любом случае приводят к усложнению (шардинг).
Различия между конструкциями платформ
Когда Cardano необходимо выполнить смарт контракт для проверки транзакции, обычно это всего лишь проверка простого скрипта. Скрипты проверки обычно содержат всего несколько простых условий (предпочтительно только одно), и их результатом является только возвращаемое значение Правда (True) или Ложь (False) (значение True позволяет расходовать UTxO). Скрипты не предназначены для выполнения сложных операций, таких как запуск других контрактов или выполнение сложных вычислений.
Смарт контракты на Cardano состоят из ончейн логики (скриптов верификации) и логики оффчейн. Все сложные операции со смарт контрактами выполняются в автономном режиме и не потребляют распределенных сетевых ресурсов. Для выполнения оффчейн логики потребляются ресурсы пользователей (кошельки) или серверов (облако). Приложения можно комбинировать, поскольку команды не ограничены возможностями платформы с точки зрения взаимодействия между собой.
Такой подход может иметь недостаток в контексте децентрализации. Многие децентрализованные приложения (DEX) в экосистеме Cardano используют дозаторы. Однако возможна децентрализация оффчейн части контрактов.
Также важно, в скольких случаях необходимо выполнить смарт контракт. У Cardano есть нативные активы, что означает, что передача токенов обеспечивается непосредственно протоколом Cardano, и нет необходимости выполнять смарт контракты (или скрипты).
Cardano также эффективен тем, что несколько токенов могут быть переданы нескольким получателям посредством одной транзакции. Это в основном экономит объем памяти и пропускную способность. DEX может создать одну крупную транзакцию, в которой имеется несколько свопов.
У Ethereum нет нативных активов. Все токены создаются с помощью смарт контрактов, которые должны выполняться при каждом взаимодействии с токенами, включая их передачу с аккаунта на аккаунт. Это предусматривает больше требований к вычислительным ресурсам сети, чем в случае с нативными ресурсами.
Смарт контракты на Ethereum в основном содержат всю логику приложения. Поэтому их выполнение сопряжено с высокими требованиями к сетевым ресурсам. Как и в случае с транзакциями, смарт контракты должны выполняться последовательно.
Почти все, что делает Ethereum, требует выполнения смарт контракта, за исключением перевода ETH.
Если мы говорим о возможностях лучшего масштабирования, необходимо смотреть на это через призму использования ресурсов. Ресурсы всегда ограничены, и цель состоит в том, чтобы максимально эффективно их использовать, то есть использовать заданное количество ресурсов для достижения максимального TPS.
Добавление нового ресурса в сеть не означает, что он будет использоваться эффективно.
Если в сети сотни нод, но только одна может работать с блоком в определенный момент времени, это неэффективно. Добавление новой ноды-производителя блоков в сеть (новые ресурсы) увеличивает децентрализацию, но не обязательно пропускную способность (координация может быть даже медленнее). Таково текущее состояние Cardano (но также Bitcoin и многих других блокчейнов).
В создании нового блока в сети Ethereum участвуют несколько нод, но это не распараллеливание. Одна нода предлагает блок, а другие ноды предварительно одобряют его. Это ускоряет финализацию блока, но не увеличивает пропускную способность сети.
Индоссанты ввода
Разницу между моделями, основанными на UTxO, и аккаунт-моделями, можно хорошо объяснить, посмотрев на функцию индоссантов ввода (IE) (Ouroboros Leios). IE - это один из способов, который может улучшить масштабируемость Cardano. Мы покажем, как IE улучшает масштабируемость Cardano, а также почему нечто подобное не может быть реализовано в случае аккаунт-модели.
Масштабируемость и эффективность Cardano можно улучшить, отделив обработку транзакций от производства блоков. Транзакции могут быть предварительно обработаны (предварительно подтверждены) сетью перед вставкой в блок. Транзакции могут быть выбраны и одобрены индоссантами ввода (случайно выбранными нодами на основе стейка). Одобренные транзакции затем распространяются по сети и обрабатываются другими нодами, прежде чем производители блоков объединят их в блоки. Блоки содержат только ссылки на одобренные транзакции.
Обратите внимание, что когда транзакции включаются в блок, они получают подтверждения от нескольких нод. Это ускоряет финализацию транзакций.
IE сокращает задержку и изменчивость времени распространения блоков, поскольку транзакции могут передаваться потоком постоянно, не дожидаясь консенсуса. Это также повышает скорость работы и ответную реакцию сети.
Транзакции могут обрабатываться параллельно разными нодами перед включением в блоки, что увеличивает пропускную способность сети. Cardano сможет обрабатывать больше транзакций (и они могут быть более сложными).
IE использует модель UTXO, точнее параллелизм.
IE отличается от шардинга, который является еще одним методом масштабирования блокчейн сетей. IE не требует взаимодействия между шардами или синхронизации, поскольку все ноды обрабатывают одни и те же одобренные транзакции, прежде чем они будут включены в блоки.
IE дополняет шардинг, поскольку может улучшить масштабируемость и эффективность каждого шарда или уровня сети. Таким образом, у Cardano может быть шардинг, как только будет реализован IE.
IE не может быть так просто применен к аккаунт-модели.
Проверка каждой транзакции зависит от проверки всех предыдущих транзакций, т.е. от глобального состояния. Ноды Ethereum не могут (заранее) проверять транзакции, не зная (будущего) глобального состояния. Аккаунт-модель требует большей синхронизации и координации между нодами, поскольку транзакции должны обновлять глобальное состояние аккаунтов.
Другими словами, ноды Ethereum не могут принимать часть транзакций и проверять их независимо от других транзакций. Проблема в том, что глобальное состояние изменяется только в одном месте сети (производителе блоков), а все остальные ноды ждут, пока они смогут проверить новый блок. Таким образом, они работают на холостом ходу (они могут только предварительно одобрить новый блок).
Шардинг
Предполагалось, что в Ethereum будет шардинг, но команда отказалась от этого намерения и теперь больше склоняется ко вторым слоям. Давайте поразмышляем о том, как мог бы выглядеть шардинг в аккаунт-модели.
Шардинг - это метод, который разбивает блокчейн на более мелкие части, называемые шардами, которые могут обрабатывать транзакции параллельно. Шардинг может повысить масштабируемость и пропускную способность сети, но он также создает новые проблемы и компромиссы.
Одна из проблем, связанных с глобальным состоянием, заключается в том, как обеспечить согласованность и безопасность транзакций между шардами, которые представляют собой транзакции, связанные с аккаунтами или контрактами на разных шардах. Транзакции между шардами требуют координации и обмена данными между шардами, что может привести к задержке и сложности.
Более того, транзакции с перекрестными шардами могут столкнуться с риском атак с двойным расходованием или переупорядочением, когда злоумышленники пытаются манипулировать порядком или валидностью транзакций.
Каждый шард имел бы свое собственное глобальное состояние, и это состояние должно было бы синхронизироваться между всеми шардами. Каждый шард мог бы иметь свое собственное независимое состояние, означающее уникальный набор остатков на счетах и смарт контрактов. Глобальное состояние сети (все шарды вместе взятые) не было бы фиксированным состоянием. Оно должно было бы быть динамичным и развивающимся состоянием, которое зависит от взаимодействий и консенсуса между шардами.
Если бы сеть имела одно состояние в отдельно взятый момент времени, это могло бы быть невероятно неэффективно и требовать большого количества коммуникаций и синхронизации.
Даже если бы у Ethereum был шардинг, он все равно страдал бы от неэффективности, связанной с глобальным состоянием. Каждый шард имел бы свое собственное глобальное состояние. В каждом шарде новый блок создавался бы независимо от других шардов (что является формой распараллеливания), но столь же неэффективным способом. То есть, в каждом раунде всегда был бы один производитель блоков, который заполнял бы блок транзакциями, и куча других нод, которые ничего не могли бы делать, кроме как дождаться этого блока, чтобы они могли его проверить. Необходимость синхронизации глобальных состояний всех шардов только усложняет все. Ноды из разных шардов должны взаимодействовать друг с другом, чтобы согласовать допустимые глобальные состояния. Причина в том, что пользователи и активы одной сети находятся в разных шардах.
Внедрение шардинга на Cardano также было бы большой проблемой. Однако это проще, чем в случае аккаунт-моделей. Как только функция индоссантов ввода будет готова, можно будет рассмотреть и шардинг.
Модель EUTxO может иметь некоторые преимущества для реализации шардинга по сравнению с аккаунт-моделью благодаря естественному параллелизму.
Несколько нод могли бы активно участвовать в шардинге одновременно. IE помог бы с этим. Транзакции могли бы передаваться потоковой передачей постоянно, не дожидаясь консенсуса, так что это уменьшило бы задержку и сложность транзакций между шардами.
Подобно аккаунт-модели, шардинг требует большей синхронизации и координации между нодами в разных шардах. Однако IE значительно улучшил бы функционирование шардинга на Cardano, поскольку это ускорило бы достижение консенсуса внутри шардов.
Ноды должны были бы знать не только о своем шарде (например, о своем собственном наборе UTxO), но и, по крайней мере, частично знать об окружающих шардах. Возможно, потребовалось бы реализовать какое-то (динамичное и эволюционирующее) глобальное состояние сети (все шарды вместе).
Реализация шардинга в аккаунт-моделях или UTxO, не является тривиальной задачей. Хотя в случае модели UTxO это могло бы быть проще (в основном благодаря параллелизму), это, безусловно, непростая задача.
Вывод
На масштабируемость блокчейнов (и платформ) влияют модель учета, дизайн сети, оптимизация и другие факторы. Например, Mithril позволит создавать клиенты без сохранения состояния, которые представляют собой ноды, которые не хранят все состояние блокчейна, а только проверяют транзакции с использованием криптографических доказательств.
На мой взгляд, масштабируемость - это, главным образом, разумное использование вычислительных ресурсов наилучшим из возможных способов и возможность добавлять ресурсы. Но у этого есть свои ограничения (в отличие от централизованных сетей), и команды должны соблюдать баланс между важными свойствами сети.
Даже если модель, основанная на UTxO, кажется более выгодной с точки зрения масштабируемости, она может оказаться не лучшим возможным решением для конкретного варианта использования, который предлагает платформа.
Лучшим активом проекта является команда, способная адаптировать проект к рыночным условиям или пожеланиям сообщества и предложить решение, необходимое для принятия в данный момент. Низкая масштабируемость является препятствием, когда она препятствует более широкому принятию. Есть проекты, которые (предположительно) имеют тысячи TPS на первом слое, но они не входят в топ-10.
// От переводчика: для получения дополнительных переведенных на русский язык статей о Cardano посетите русскоязычный раздел на форуме Cardano. Видеоролики о Cardano на русском языке можно найти на YouTube канале нашего замечательного амбасадора Тимура Сахабутдинова, а также на канале Чарльз Хоскинсон на русском. Хотите поговорить или задать вопрос о Cardano? Тогда приглашаем в наше уютное русскоязычное сообщество Cardano в Telegram. Оставайтесь на связи, все только начинается!